[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