[llvm] [ConstantMerge] Only merge constant w/unnamed_addr (PR #124050)
via llvm-commits
llvm-commits at lists.llvm.org
Thu Jan 23 19:07:38 PST 2025
gulfemsavrun wrote:
> I agree. There isn't any direct connection between the linkage of a global, and whether it's unnamed_addr. Maybe constant merging needs a check to ensure it doesn't change the linkage of globals used by a pointer subtraction?
>
> Okay, that's what I expected: pointer subtraction like that only works if both symbols are "local" (in the ELF sense). ConstantMerge isn't aware of the pointer subtraction, so it blindly merges without checking for that.
>
> unnamed_addr is a red herring: unnamed_addr is correlated with symbol linkage for C strings work, but it's not directly connected to the issue. clang generates unnamed_addr variables with default linkage in some cases.
Thanks for the feedback @efriedma-quic. It is becoming more clear that the issue in `ConstantMerge` pass is more about linkage type than `unnamed_addr`. Merging a `non-unnamed_addr` constant into an `unnamed_addr` constant might still be questionable in terms of language semantics, but that's kind of separate. How do you feel about adding a local linkage check in `ConstantMerge` like in https://github.com/llvm/llvm-project/pull/124220? Is it too conservative? This might be another solution for the problem that we ran into with `RelLookupTableConverterPass`.
https://github.com/llvm/llvm-project/pull/124050
More information about the llvm-commits
mailing list