[X86] Emit @PLT for x86-64 and keep unadorned symbols for x86-32
authorFangrui Song <i@maskray.me>
Sat, 5 Dec 2020 21:17:47 +0000 (13:17 -0800)
committerFangrui Song <i@maskray.me>
Sat, 5 Dec 2020 21:17:47 +0000 (13:17 -0800)
commit37f0c8df47d84ba311fc9a2c1884935ba8961e84
treea888e988c4c5af8e210e3f4abe71f776c374ed0e
parent9737c128f14d60f73b1d198453801a05b37c6b28
[X86] Emit @PLT for x86-64 and keep unadorned symbols for x86-32

This essentially reverts the x86-64 side effect of r327198.

For x86-32, @PLT (R_386_PLT32) is not suitable in -fno-pic mode so the
code forces MO_NO_FLAG (like a forced dso_local) (https://bugs.llvm.org//show_bug.cgi?id=36674#c6).

For x86-64, both `call/jmp foo` and `call/jmp foo@PLT` emit R_X86_64_PLT32
(https://sourceware.org/bugzilla/show_bug.cgi?id=22791) so there is no
difference using @PLT. Using @PLT is actually favorable because this drops
a difference with -fpie/-fpic code and makes it possible to avoid a canonical
PLT entry when taking the address of an undefined function symbol.
23 files changed:
llvm/lib/Target/X86/X86Subtarget.cpp
llvm/test/CodeGen/X86/cvt16.ll
llvm/test/CodeGen/X86/extract-fp.ll
llvm/test/CodeGen/X86/extractelement-fp.ll
llvm/test/CodeGen/X86/finite-libcalls.ll
llvm/test/CodeGen/X86/fmaxnum.ll
llvm/test/CodeGen/X86/fmf-flags.ll
llvm/test/CodeGen/X86/fminnum.ll
llvm/test/CodeGen/X86/fp128-extract.ll
llvm/test/CodeGen/X86/fp128-i128.ll
llvm/test/CodeGen/X86/fp128-libcalls.ll
llvm/test/CodeGen/X86/half.ll
llvm/test/CodeGen/X86/llround-conv.ll
llvm/test/CodeGen/X86/lround-conv-i32.ll
llvm/test/CodeGen/X86/lround-conv-i64.ll
llvm/test/CodeGen/X86/memcpy-inline.ll
llvm/test/CodeGen/X86/memcpy.ll
llvm/test/CodeGen/X86/memset-nonzero.ll
llvm/test/CodeGen/X86/negative-sin.ll
llvm/test/CodeGen/X86/pow.ll
llvm/test/CodeGen/X86/powi.ll
llvm/test/CodeGen/X86/pr38865.ll
llvm/test/CodeGen/X86/vector-half-conversions.ll