[all-commits] [llvm/llvm-project] 232e0a: [lto] Do not try to internalize symbols with escap...

[serge-sans-paille via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 232e0a011e8c07053bdc0156f312046eb09f52b3
      https://github.com/llvm/llvm-project/commit/232e0a011e8c07053bdc0156f312046eb09f52b3
  Author: serge-sans-paille <sguelton at redhat.com>
  Date:   2022-10-14 (Fri, 14 Oct 2022)

  Changed paths:
    M llvm/lib/LTO/LTO.cpp
    A llvm/test/LTO/X86/hidden-escaped-symbols-alt.ll
    A llvm/test/LTO/X86/hidden-escaped-symbols.ll
    A llvm/test/ThinLTO/X86/hidden-escaped-symbols-alt.ll
    A llvm/test/ThinLTO/X86/hidden-escaped-symbols.ll

  Log Message:
  -----------
  [lto] Do not try to internalize symbols with escaped name

Because of LLVM mangling escape sequence (through '\01' prefix), it is possible
for a single symbols two have two different IR representations.

For instance, consider @symbol and @"\01_symbol". On OSX, because of the system
mangling rules, these two IR names point are converted in the same final symbol
upon linkage.

LTO doesn't model this behavior, which may result in symbols being incorrectly
internalized (if all reference use the escaping sequence while the definition
doesn't).

The proper approach is probably to use the mangled name to compute GUID to
avoid the dual representation, but we can also avoid discarding symbols that are
bound to two different IR names. This is an approximation, but it's less
intrusive on the codebase.

Fix #57864

Differential Revision: https://reviews.llvm.org/D135710