[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