[llvm] add CallBrPrepare pass to pipelines

[nickdesaulniers]

Summary

Capstone of
https://discourse.llvm.org/t/rfc-syncing-asm-goto-with-outputs-with-gcc/65453/8

Clang changes are still necessary to enable the use of outputs along
indirect edges of asm goto statements.

Link: https://github.com/llvm/llvm-project/issues/53562

[nickdesaulniers]

• remove TODOs from commit message

[nickdesaulniers]

TODO: add llvm/docs/LangRef.rst change from D138078.

[nickdesaulniers]

• add langref changes from D138078

[nickdesaulniers]

Ready for review:

1. https://reviews.llvm.org/D135997
2. https://reviews.llvm.org/D140166
3. https://reviews.llvm.org/D139861
4. https://reviews.llvm.org/D139872
5. https://reviews.llvm.org/D139883
6. https://reviews.llvm.org/D139970
7. https://reviews.llvm.org/D140160
8. https://reviews.llvm.org/D137113
9. https://reviews.llvm.org/D136497

[nickdesaulniers]

• rebase, format

[nickdesaulniers]

Now that Loongarch has been merged, I need to fix failures in the following tests:

LLVM :: CodeGen/LoongArch/O0-pipeline.ll
LLVM :: CodeGen/LoongArch/opt-pipeline.ll

[nickdesaulniers]

• rebase, fix loongarch tests

[nickdesaulniers]

• rebase

[efriedma]

llvm/docs/LangRef.rst

8544

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.

llvm/lib/CodeGen/MachineVerifier.cpp

632

80 cols?

[jyknight]

llvm/docs/LangRef.rst

8544

"indirect labels" are one of the arguments to the "callbr" instruction (see above syntax description and below description in "Arguments")

[efriedma]

llvm/docs/LangRef.rst

8544

Okay, but then how do you pass a label as a "function args"?

[nickdesaulniers]

• 80 cols

[nickdesaulniers]

llvm/docs/LangRef.rst

8544

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?

[efriedma]

llvm/docs/LangRef.rst

8544

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.)

[jyknight]

llvm/docs/LangRef.rst

8544

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.

[nickdesaulniers]

llvm/docs/LangRef.rst

8544

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?

[efriedma]

llvm/docs/LangRef.rst

8544

Just say that blockaddress constants which refer to a block will not compare equal to indirect labels referring to the same block? I guess?

[jyknight]

llvm/docs/LangRef.rst

8544

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.

[nickdesaulniers]

• update langref as per @efriedma using @jyknight's wording

[nickdesaulniers]

• rebase

[nickdesaulniers]

• final rebase

[nickdesaulniers]

commit cf86855c4453 ("[M68k] fix test regression introduced by D140180")