ir: use value.Value for operands of instructions? about llvm HOT 5 CLOSED

I played with the official python API and everything being a value (including instructions that do not return a value) was bewildering. Don't know what's better in this case, though.

from llvm.

Hi @hosewiejacke

I played with the official python API and everything being a value (including instructions that do not return a value) was bewildering. Don't know what's better in this case, though.

I agree, you kind of feel like a compiler construction Wizard when everything can be used as an operand to everything else.

I think we've struck a good balance atm with what instructions implement the value.Value interface. Essentially, anything you can use as an operand to another instruction is a value. The few remaining instructions, mostly fence and store which instead only implement the ir.Instruction and can thus only be appended to the list of instructions in a basic block.

Regarding this issue, we are trying to figure out if relaxing the type constraints on the concrete struct types of various instructions may allow for more powerful data flow analysis APIs in future releases of llir/llvm. There is an obvious trade-off. The more concrete of a type you have as members of the structs, the more knowledge is presented to the user, e.g. using *ir.BasicBlock for the target of a branch instruction provides more knowledge than if we use a value.Value.

However, if we relax this and use value.Value throughout, then we could have APIs that allow not only retrieval of information about value uses throughout the IR, but also makes it possible to have APIs that update the values through *value.Value pointer access.

We will continue to collect information, and see what are the various benefits and drawbacks with different approaches. I think I'm starting to lean more and more to the side of using value.Value throughout. We will see :)

Wish you a great winter holidays and happy coding!

Cheers,
Robin

from llvm.

Hmm, I've been using the help wanted labels for indicating that we'd like to get more input and various views for the design discussions. Perhaps this label is more often interpreted to mean something along the lines of we need help to implement this rather than please join our discussion to nail the API. Should we add a new label (e.g. ongoing discussion, user input wanted, or something along those lines) instead?

cc: @pwaller.

from llvm.

from llvm.

Perhaps this label is more often interpreted to mean something along the lines of we need help to implement this
Yes, that's how I interpret it.
Should we add a new label (e.g. ongoing discussion, user input wanted, or something along those lines) instead?
SGTM.

Good. I've added the proposal label now, perhaps that is enough to indicate that this is a design decision that needs to be fleshed out and that welcome anyone to contribution to the discussion.

from llvm.