[PATCH] D139565: [IR] add new callbrpad instruction

Nicolai Hähnle via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Dec 8 11:17:09 PST 2022


nhaehnle added a comment.

>From an LLVM IR perspective, it seems there is inherently the issue that whatever code the `callbr` invokes may produce values that are available in all successors, but it may also produce values that are only available in some subset of successors. In the spirit of keeping LLVM IR, can we solve that issue in a way that isn't too focused on the details of inline assembly?

How about:

- The value defined by the `callbr` is accessible to all successors, i.e. all successors of a `callbr` are equal and there's no special treatment in the dominator tree and/or SSA checking.
- For successors that do get additional values that are not universally available, `callbrpad` can be used. Again, all successors of a `callbr` are equal, and the "direct" successor may have a `callbrpad`.

An observation that may help with the design is that if we had basic block arguments, then the `callbrpad` would just be another argument next to potential `phi`s. This makes me dislike the name `callbrpad` as the term "pad" is slightly vague and seems to suggest something more complex going on. How about `callbrdef` or maybe even just `terminatordef`? The point is that the instruction in reality merely represents a value that is defined by the terminator of the predecessor.

(Side note: I don't understand why the diff puts so much emphasis on physical registers in the description of `callbrpad`. I would expect the issue to exist regardless of how the inlineasm constrains the output.)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D139565/new/

https://reviews.llvm.org/D139565



More information about the llvm-commits mailing list