[all-commits] [llvm/llvm-project] e0586e: [RelLookupTableConverter] Drop unnamed_addr to avo...
dianqk via All-commits
all-commits at lists.llvm.org
Tue Jun 3 14:50:05 PDT 2025
Branch: refs/heads/release/20.x
Home: https://github.com/llvm/llvm-project
Commit: e0586e278f96e4f104c8b8039a41c6832c35be22
https://github.com/llvm/llvm-project/commit/e0586e278f96e4f104c8b8039a41c6832c35be22
Author: dianqk <dianqk at dianqk.net>
Date: 2025-06-03 (Tue, 03 Jun 2025)
Changed paths:
M llvm/lib/Transforms/Utils/RelLookupTableConverter.cpp
A llvm/test/Transforms/RelLookupTableConverter/unnamed_addr.ll
Log Message:
-----------
[RelLookupTableConverter] Drop unnamed_addr to avoid generating GOTPCREL relocations (#142304)
Follow
https://github.com/llvm/llvm-project/pull/72584#issuecomment-2925759253,
the patch will drop the `unnamed_addr` attribute when generating
relative lookup tables. I'm not very confident about this patch, but it
does resolve https://github.com/rust-lang/rust/issues/140686,
https://github.com/rust-lang/rust/issues/141306 and
https://github.com/rust-lang/rust/issues/141737.
But I don't think this will result in worse problems.
> LLVM provides that the calculation of such a constant initializer will
not overflow at link time under the medium code model if x is an
unnamed_addr function. However, it does not provide this guarantee for a
constant initializer folded into a function body. This intrinsic can be
used to avoid the possibility of overflows when loading from such a
constant. ([‘llvm.load.relative’
Intrinsic](https://llvm.org/docs/LangRef.html#id2592))
This is my concern. I'm not sure how unnamed_addr provides this
guarantee, and I haven't found any test cases.
(cherry picked from commit aa09dbbbcfd4724bd04eea48763a1322f659637d)
To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications
More information about the All-commits
mailing list