[all-commits] [llvm/llvm-project] a6ac96: [Arm64EC] Refer to dllimport'ed functions correctly.

[Eli Friedman via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: a6ac968360183013affa8cb372bd5b80cba00ac9
      https://github.com/llvm/llvm-project/commit/a6ac968360183013affa8cb372bd5b80cba00ac9
  Author: Eli Friedman <efriedma at quicinc.com>
  Date:   2022-10-20 (Thu, 20 Oct 2022)

  Changed paths:
    M llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
    M llvm/lib/Target/AArch64/AArch64InstrInfo.cpp
    M llvm/lib/Target/AArch64/AArch64MCInstLower.cpp
    M llvm/lib/Target/AArch64/AArch64Subtarget.cpp
    M llvm/lib/Target/AArch64/Utils/AArch64BaseInfo.h
    A llvm/test/CodeGen/AArch64/arm64ec-dllimport.ll

  Log Message:
  -----------
  [Arm64EC] Refer to dllimport'ed functions correctly.

Arm64EC has two different ways to refer to dllimport'ed functions in an
object file. One is using the usual __imp_ prefix, the other is using an
Arm64EC-specific prefix __imp_aux_. As far as I can tell, if a function
is in an x64 DLL, __imp_aux_ refers to the actual x64 address, while
__imp_ points to some linker-generated code that calls the exit thunk.
So __imp_aux_ is used to refer to the address in non-call contexts,
while __imp_ is used for calls to avoid the indirect call checker.

There's one twist to this, though: if an object refers to a symbol using
the __imp_aux_ prefix, the object file's symbol table must also contain
the symbol with the usual __imp_ prefix. The symbol doesn't actually
have to be used anywhere, it just has to exist; otherwise, the linker's
symbol lookup in x64 import libraries doesn't work correctly. Currently,
this is handled by emitting a .globl __imp_foo directive; we could try
to design some better way to handle this.

One minor quirk I haven't figured out: apparently, in Arm64EC mode, MSVC
prefers to use a linker-synthesized stub to call dllimport'ed functions,
instead of branching directly. The linker stub appears to do the same
thing that inline code would do, so not sure if it's just a code-size
optimization, or if the synthesized stub can actually do something other
than just load from the import table in some circumstances.

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