[all-commits] [llvm/llvm-project] 9ba8c4: Fix behavior of ifuncs with 'used' extern "C" stat...

[Erich Keane via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 9ba8c4024b52bb8d0491fa1d15790ce7e9a9eae1
      https://github.com/llvm/llvm-project/commit/9ba8c4024b52bb8d0491fa1d15790ce7e9a9eae1
  Author: Erich Keane <erich.keane at intel.com>
  Date:   2022-04-01 (Fri, 01 Apr 2022)

  Changed paths:
    M clang/lib/CodeGen/CodeGenModule.cpp
    M clang/lib/CodeGen/CodeGenModule.h
    A clang/test/CodeGenCXX/externc-ifunc-resolver.cpp
    A clang/test/SemaCXX/externc-ifunc-resolver.cpp

  Log Message:
  -----------
  Fix behavior of ifuncs with 'used' extern "C" static functions

We expect that `extern "C"` static functions to be usable in things like
inline assembly, as well as ifuncs:
See the bug report here: https://github.com/llvm/llvm-project/issues/54549

However, we were diagnosing this as 'not defined', because the
ifunc's attempt to look up its resolver would generate a declared IR
function.

Additionally, as background, the way we allow these static extern "C"
functions to work in inline assembly is by making an alias with the C
mangling in MOST situations to the version we emit with
internal-linkage/mangling.

The problem here was multi-fold: First- We generated the alias after the
ifunc was checked, so the function by that name didn't exist yet.
Second, the ifunc's generation caused a symbol to exist under the name
of the alias already (the declared function above), which suppressed the
alias generation.

This patch fixes all of this by moving the checking of ifuncs/CFE aliases
until AFTER we have generated the extern-C alias.  Then, it does a
'fixup' around the GlobalIFunc to make sure we correct the reference.

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