[PATCH] D121970: [Verify] check that BlockAddresses don't refer to functions with certain linkages which wont be emitted
Duncan P. N. Exon Smith via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Mar 18 11:44:51 PDT 2022
dexonsmith added a comment.
In D121970#3392955 <https://reviews.llvm.org/D121970#3392955>, @efriedma wrote:
> If a function definition gets discarded, the values of blockaddresses which refer to that definition don't matter.
This is the piece I was missing (which led to me suggesting there should be a verifier check).
Looks like this *is* documented in LangRef, which I think makes it clear:
https://llvm.org/docs/LangRef.html#addresses-of-basic-blocks
> This value only has defined behavior when used as an operand to the `indirectbr` or `callbr` instruction, or for comparisons against null.
Due to this, I now understand why `blockaddress` is lowered to constant non-null value if the function is not selected; seems like it's safe enough.
Also:
> https://reviews.llvm.org/D120781#3383492 has an example of a blockaddress in a linkonce_odr global variable, but I'm pretty sure that has undefined behavior at the IR level. A blockaddress in one translation unit is never equivalent to a blockaddress in another translation unit, so it breaks the rules for linkonce_odr. It might make sense for clang to diagnose that.
I agree; based on LangRef, that has UB at the IR level. Having Clang diagnose it probably makes sense.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D121970/new/
https://reviews.llvm.org/D121970
More information about the llvm-commits
mailing list