[all-commits] [llvm/llvm-project] 3bf1ac: [CMake][ELF] Add -fno-semantic-interposition and -...

Fangrui Song via All-commits all-commits at lists.llvm.org
Wed May 12 10:34:56 PDT 2021


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 3bf1acab5b454ad7fb2074b34663108b53620695
      https://github.com/llvm/llvm-project/commit/3bf1acab5b454ad7fb2074b34663108b53620695
  Author: Fangrui Song <i at maskray.me>
  Date:   2021-05-12 (Wed, 12 May 2021)

  Changed paths:
    M clang/tools/clang-shlib/CMakeLists.txt
    M llvm/cmake/modules/HandleLLVMOptions.cmake
    M llvm/tools/llvm-shlib/CMakeLists.txt

  Log Message:
  -----------
  [CMake][ELF] Add -fno-semantic-interposition and -Bsymbolic-functions

llvm-dev message: https://lists.llvm.org/pipermail/llvm-dev/2021-May/150465.html

In an ELF shared object, a default visibility defined symbol is preemptible by default.
This creates some missed optimization opportunities. -fno-semantic-interposition can optimize -fPIC:

* in Clang: avoid GOT/PLT cost for variable access/function calls to external linkage definition in the same TU
* in GCC: enable interprocedural optimizations (including inlining) and avoid PLT

See https://gist.github.com/MaskRay/2d4dfcfc897341163f734afb59f689c6 for more information.

-Bsymbolic-functions is more aggressive than -fvisibility-inlines-hidden (present since 2012) as it applies
to all function definitions.  It can

* avoid PLT for cross-TU function calls && reduce dynamic symbol lookup
* reduce dynamic symbol lookup for taking function addresses and optimize out GOT/TOC on x86-64/ppc64

With both options, the libLLVM.so and libclang-cpp.so performance should
be closer to PIE binary linking against `libLLVM*.a` and `libclang*.a`

(In a -DLLVM_TARGETS_TO_BUILD=X86 build, the number of JUMP_SLOT decreases from 12716 to 1628, and the number of GLOB_DAT decreases from 1918 to 1313
The built clang with `-DLLVM_LINK_LLVM_DYLIB=on -DCLANG_LINK_CLANG_DYLIB=on` is significantly faster.
See the Linux kernel build result https://bugs.archlinux.org/task/70697
)

Some implication:

Interposing a subset of functions is no longer supported.
(This is fragile anyway and cannot really be supported. For Mach-O we don't use
`ld -interpose`, so interposition is not supported on Mach-O at all.)

Compiling a program which takes the address of any LLVM function with
`{gcc,clang} -fno-pic` and expects the address to equal to the address taken
from libLLVM.so or libclang-cpp.so is unsupported. I am fairly confident that
llvm-project shouldn't have different behaviors depending on such pointer
equality (as we've been using -fvisibility-inlines-hidden which applies to
inline functions for a long time), but if we accidentally do, users should be
aware that they should not make assumption on pointer equality in `-fno-pic`
mode.

Reviewed By: phosek

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


  Commit: 0fe6649bc5b1824e87e418b2b18f61c1ed1025ce
      https://github.com/llvm/llvm-project/commit/0fe6649bc5b1824e87e418b2b18f61c1ed1025ce
  Author: Fangrui Song <i at maskray.me>
  Date:   2021-05-12 (Wed, 12 May 2021)

  Changed paths:
    M llvm/lib/Target/X86/X86ISelLowering.cpp

  Log Message:
  -----------
  [X86] Fix -Wunused-lambda-capture


Compare: https://github.com/llvm/llvm-project/compare/5480ea6c8463...0fe6649bc5b1


More information about the All-commits mailing list