[PATCH] D140180: [llvm] add CallBrPrepare pass to pipelines

[Nick Desaulniers via Phabricator via llvm-commits]

nickdesaulniers 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
----------------
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?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D140180