[Openmp-commits] [openmp] [openmp] Add support for arm64ec to libomp (PR #176151)

[David Truby via Openmp-commits]

================
@@ -134,7 +135,7 @@ kmp_uint64 __kmp_test_then_and64(volatile kmp_uint64 *p, kmp_uint64 d) {
   return old_value;
 }
 
-#if KMP_ARCH_AARCH64 && KMP_COMPILER_MSVC
+#if (KMP_ARCH_AARCH64 && KMP_COMPILER_MSVC) || KMP_ARCH_ARM64EC
----------------
DavidTruby wrote:

> I’m not sure what you mean; such an arm64ec function should have an entry thunk. If it doesn't, it's a bug.

My though process was something like this:
If you take the address of a function in Arm64EC mode, then you have the address to the start of the actual arm64ec function, _not_ the entry thunk; otherwise calling that pointer wouldn't work from other arm64ec code. If you pass that into an x86_64 abi function without casting the type or anything, I'd expect the toolchain to then correct the pointer to be the pointer to the entry thunk at that point. However, if you cast the pointer around between different types, and even worse eventually end up at a different type than you started at (`microtask_t` in this case) then how can the toolchain know what the address even is? It might be an x86_64 function address, it might be an arm64ec one, etc. So it can't fix it up to refer to the entry thunk, and the call will just explode in x86_64.

I may have misunderstood how the emulator works here though. Maybe on the emulation side it somehow knows how to fix the function pointers, rather than it being toolchain-side?

Anyways, as long as we are happy to only assume support for clang and flang as users of this function, assuming that the functions are actually never variadic is safe. Clang and Flang only ever generate non-variadic signatures for the outlined functions so there shouldn't be any issue here.

https://github.com/llvm/llvm-project/pull/176151