diff options
| author | dianqk <dianqk@dianqk.net> | 2025-06-01 22:17:57 +0800 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2025-06-01 22:17:57 +0800 |
| commit | aa09dbbbcfd4724bd04eea48763a1322f659637d (patch) | |
| tree | 71add2d74e64bcd3750234a7bb07ba21464938b7 /clang/lib/Serialization/ModuleManager.cpp | |
| parent | 71079fcb8e2f3f25bf06740d4bbc498ee075459c (diff) | |
| download | llvm-aa09dbbbcfd4724bd04eea48763a1322f659637d.zip llvm-aa09dbbbcfd4724bd04eea48763a1322f659637d.tar.gz llvm-aa09dbbbcfd4724bd04eea48763a1322f659637d.tar.bz2 | |
[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.
Diffstat (limited to 'clang/lib/Serialization/ModuleManager.cpp')
0 files changed, 0 insertions, 0 deletions