[Openmp-commits] [openmp] [openmp] Add support for arm64ec to libomp (PR #176151)
Jacek Caban via Openmp-commits
openmp-commits at lists.llvm.org
Thu Jan 15 05:58:05 PST 2026
================
@@ -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
----------------
cjacek wrote:
Thanks for working on this. I looked into this in the past (see #138769), where I implemented an assembly version, but it had its own issues and we ended up disabling openmp in llvm-mingw for now. See the comments in that MR for details.
The tricky part about this function is that, unlike on other platforms, calling a varargs function is not the same as calling a regular function. That is, `((void (*)(int,int))f)(0,1)` uses a different calling convention and exit thunk than `((void (*)(int,...))f)(0,1)`. For example, with this C implementation, if a non-varargs ARM64EC function is passed as `pkfn` and invoked with five arguments, the fifth argument will be passed on the stack instead of in a register. In addition, varargs ARM64EC functions expect x5 to contain the size of the arguments passed on the stack, which the `alloca` hack does not take into account.
For cases like this, the most reliable solution would be to use x86_64 assembly instead (and build it as x86_64). That may be tricky for the build system, though. See https://github.com/mingw-w64/mingw-w64/commit/6d653e07ece813ab71f2e1e214dbef63f2fe250a for an example of how a similar problem is handled in mingw-crt.
https://github.com/llvm/llvm-project/pull/176151
More information about the Openmp-commits
mailing list