[all-commits] [llvm/llvm-project] aa16de: [Linker] Propagate `nobuiltin` attributes when lin...

[Joseph Huber via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: aa16de6399a42421076ed642c3b4f7fb12c6d44b
      https://github.com/llvm/llvm-project/commit/aa16de6399a42421076ed642c3b4f7fb12c6d44b
  Author: Joseph Huber <huberjn at outlook.com>
  Date:   2024-05-09 (Thu, 09 May 2024)

  Changed paths:
    M llvm/include/llvm/Linker/IRMover.h
    M llvm/lib/Linker/CMakeLists.txt
    M llvm/lib/Linker/IRMover.cpp
    A llvm/test/Linker/Inputs/strlen.ll
    A llvm/test/Linker/libcalls.ll

  Log Message:
  -----------
  [Linker] Propagate `nobuiltin` attributes when linking known libcalls (#89431)

Summary:
As discussed in
https://discourse.llvm.org/t/rfc-libc-ffreestanding-fno-builtin.

LLVM ascribes special semantics to several functions that are known to
be `libcalls`. These are functions that middle-end optimizations may
transforms calls into or perform optimizations based off of known
semantics. However, these assumptions require an opaque function call to
be known valid. In situations like LTO or IR linking it is possible to
bring a libcall definition into the current module. Once this happens,
we can no longer make any guarantees about the semantics of these
functions.

We currently attempt to solve this by preventing all inlining if the
called function has `no-builtin` https://reviews.llvm.org/D74162.
However, this is overly pessimistic as it prevents all inlining even for
non-libcall functions.

This patch modifies the IRMover class to track known libcalls enabled
for the given target. If we encounter a known libcall during IR linking,
we then need to append the `nobuiltin` attribute to the destination
module. Afterwards, all new definitions we link in will be applied as
well.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications