[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