[PATCH] D140180: [llvm] add CallBrPrepare pass to pipelines
James Y Knight via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Jan 31 05:52:55 PST 2023
jyknight added inline comments.
================
Comment at: llvm/docs/LangRef.rst:8537
+To support outputs along indirect edges, LLVM may need to split critical edges.
+This means that basic blocks may be synthesized; ``indirect labels`` from
+inline asm may not compare equal to the label when passed as a
----------------
efriedma wrote:
> nickdesaulniers wrote:
> > jyknight wrote:
> > > efriedma wrote:
> > > > nickdesaulniers wrote:
> > > > > efriedma wrote:
> > > > > > jyknight wrote:
> > > > > > > efriedma wrote:
> > > > > > > > Labels aren't a thing in LLVM IR; if you mean "blockaddress", please state that explicitly. Otherwise, I'm not sure what you're referring to.
> > > > > > > "indirect labels" are one of the arguments to the "callbr" instruction (see above syntax description and below description in "Arguments")
> > > > > > Okay, but then how do you pass a label as a "function args"?
> > > > > > Labels aren't a thing in LLVM IR
> > > > >
> > > > > ```
> > > > > callbr void asm "", "r,!i"(i32 %x)
> > > > > to label %fallthrough [label %indirect]
> > > > > ```
> > > > >
> > > > > I see the word label twice there.
> > > > >
> > > > > I'm also using language consistent with the rest of this section of the langref.
> > > > > https://llvm.org/docs/LangRef.html#callbr-instruction
> > > > >
> > > > > Perhaps the langref could use a fresh coat of paint here? But can that be orthogonal to this patch?
> > > > The part I'm confused about is that I'm not sure what you mean by passing a label as a function argument. (Yes, labels exist in LLVM IR in the sense you're talking about, but they don't have an address you can pass as an argument.)
> > > Oh, I see what you mean. Maybe something like the following?
> > >
> > > Note that in order to support outputs along indirect edges, LLVM may need to split critical edges, which may require synthesizing a replacement block for the indirect labels. Therefore, each `callbr` instruction must only transfer control to the addresses provided via its own indirect labels, and not addresses from a different `callbr` instruction or `blockaddress` value for the same blocks.
> > That's not precisely the point I'm trying to make. I'm trying to state that:
> >
> > asm goto ("# %0 %1"::"i"(&&foo)::foo);
> >
> > that `%0` and `%1` are no longer guaranteed to compare equal if we have to split the critical edge to `foo`. `%0` will be the final destination, while `%1` will be the synthesized block. How's best to reword this point?
> Just say that `blockaddress` constants which refer to a block will not compare equal to indirect labels referring to the same block? I guess?
Try 2:
Note that in order to support outputs along indirect edges, LLVM may need to split critical edges, which may require synthesizing a replacement block for the indirect labels. Therefore, the address of a label as seen by another callbr instruction, or for a blockaddress constant, may not be equal to the address provided for the same block to this instruction's indirect labels operand. The assembly code may only transfer control to addresses provided via this instruction's indirect labels.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D140180/new/
https://reviews.llvm.org/D140180
More information about the llvm-commits
mailing list