support for _mm_clmulepi64_si128 on Apple Silicon

[victorshoup]

I'm running macOS 15.7.1 on an Apple M1 Max.
I tried using the _mm_clmulepi64_si128 intrinsic, but it seems to end up not using the vmull_p64.
Looking at the file x86/clmul.h, I see the relevant logic is at line 202.
On my platform, the macros SIMDE_ARM_NEON_A64V8_NATIVE and clang are defined and SIMDE_ARCH_ARM_AES are undefined.
I'm using the standard g++ with -march=native.
g++ --version says:
Apple clang version 17.0.0 (clang-1700.3.19.1)
Target: arm64-apple-darwin24.6.0

So I see why the logic in x86/clmul.h chooses not to use vmull_p64, but is this an intrinsic limitation on my platform or something else.
I mean, does the Apple silicon simply not support vmull_p64, or is there some issue in the toolchain that just prevents it from being used.

Thanks for any insight on this.

[victorshoup]

I played around with this a bit further.
I found that on my platform I could, in fact, invoke the hardware PCLMUL instruction via asm.
For example:

inline static __m128i
arm_pclmul(__m128i a, __m128i b)
{
__m128i res;
asm ("pmull %0.1q, %1.1d, %2.1d \n\t"
: "=w" (res) : "w" (a), "w" (b) );
return res;
}

This works, but it only gives you _mm_clmulepi64_si128(a, b, 0), which is all I need for my application.
Presumably, you could implement the other variants _mm_clmulepi64_si128(a, b, imm8) by just writing out the 4 different cases of imm8, which the compiler should anyway optimize down to one such asm.

I would think you could implement this in your library. I see you already do use some asm here and there...

[mr-c]

Hello @victorshoup ; which version of SIMDe are you using?

I guess you are looking at the code at

simde/simde/x86/clmul.h

Lines 206 to 216 in 9130a9f

	#elif defined(SIMDE_ARM_NEON_A64V8_NATIVE) && defined(SIMDE_ARCH_ARM_AES) && !defined(__clang__)
	#define simde_mm_clmulepi64_si128(a, b, imm8) \
	simde__m128i_from_neon_u64( \
	vreinterpretq_u64_p128( \
	vmull_p64( \
	vgetq_lane_p64(vreinterpretq_p64_u64(simde__m128i_to_neon_u64(a)), (imm8 ) & 1), \
	vgetq_lane_p64(vreinterpretq_p64_u64(simde__m128i_to_neon_u64(b)), (imm8 >> 4) & 1) \
	) \
	) \
	)
	#endif

The && !defined(__clang__) which skips if the compiler is clang was added in 1e1bd76

Maybe newer clang versions don't have that bug anymore. You can try removing the && !defined(__clang__) and report back if it works for you. And yes, the other option to explore is to manually handle the 4 cases of imm8

[victorshoup]

@mr-c
Thanks for getting back to me!

I just installed simde using homebrew...it is v0.8.2. I see the github version is 0.8.4.
However, the relevant code is unchanged.

Note also that on my platform, SIMDE_ARCH_ARM_AES is also undefined, so it also wouldn't trigger the desired code because of that..
Note that I'm compiling with -march=native. This flag is supported on my compiler, and it does successfully detect other things, like the fact that neon is available.

Is AES really the right thing to test for? Seems counter-intuitive, but I'm no expert.

For now I'll have to stick with my asm hackery...it works, and the way my software is structured, I can afford to compile and run programs at config time to see what actually works and what doesn't...so I don't have to rely only on predefined macros.

[mr-c]

Thanks for the AES tip, I'm going to test this and your other suggestion in #1350

Can you share a bit about how you are using SIMDe; as part of your own project or in improving the portability of another codebase?

[victorshoup]

@mr-c
This is for a library I've been developing / maintaining for 30 years (https://libntl.org/).
For many years, I tried to use purely portable code, but eventually had to give up and take advantage of specific hardware features.
When x86 ruled the land, I started employing some AVX intrinsics here and there.
But now ARM, especially Apple Silicon, is taking over...in fact, I no longer have access to an up-to-date x86 machine (just a 10-year old macbook running Intel).

Anyway, my short term goal is to adapt SIMDE as best I can to utilize the AVX intrinsics I already am using.
One thing I want to be able to do is to make sure I only enable these intrinsics for machines that come close to natively supporting the AVX intrinsics I need.
So for now, I'm just enabling 64-bit NEON based machines, looking at the assembly code I get and doing performance testing to make sure there are no regressions.

Amazingly, thanks to SIMDE, with just a couple of days work, I've achieved 90% of what I want to do in this regard.
But as you can see, it wasn't quite as frictionless as I would have liked...

Thanks again for your great library and your help!

[victorshoup]

I see you have proposed some changes. I'll try them out... I'm curious to see if in the PCLMUL code all of that "lane shifting" code gets compiled to a NOOP when imm8==0. If not, maybe I can ask you to put some branching code around it which will surely be compiled away...

[mr-c]

I'm using the standard g++ with -march=native.
g++ --version says:
Apple clang version 17.0.0 (clang-1700.3.19.1)

Okay, I'm still seeing failures on the CI with "Apple clang version 16.0.0 (clang-1600.0.26.3)" and "Ubuntu clang version 20.1.2 (0ubuntu1~24.04.2)"

https://github.com/simd-everywhere/simde/actions/runs/18593902918/job/53015168531?pr=1350#step:8:532
https://github.com/simd-everywhere/simde/actions/runs/18593902918/job/53015168668?pr=1350#step:8:532

I think the AES check was incorrect, thank you. The remaining issue is similar to llvm/llvm-project#149329

[mr-c]

@victorshoup Thank you for the back story, that is really great to hear!

[mr-c]

I see you have proposed some changes. I'll try them out... I'm curious to see if in the PCLMUL code all of that "lane shifting" code gets compiled to a NOOP when imm8==0. If not, maybe I can ask you to put some branching code around it which will surely be compiled away...

Alas the workaround didn't succeed.

[victorshoup]

@mr-c
Indeed...I left a comment in the PR

[victorshoup]

@mr-c
This is unfortunate...Apple Silicon is big share of the ARM market these days, and it would be nice to have a working PCLMUL.

By the way, while the code directly from SIMDE fails to compile under gcc-15, so does my asm hack :-(
I get:

/var/folders/4x/b4m6zx_x2mjbcfn68rkg769m0000gn/T//ccb74Knk.s:81:2: error: instruction requires: aes
pmull v30.1q, v31.1d, v30.1d
^
/var/folders/4x/b4m6zx_x2mjbcfn68rkg769m0000gn/T//ccb74Knk.s:241:2: error: instruction requires: aes
pmull v31.1q, v31.1d, v30.1d

This is sad...actually, I didn't think that the compiler even checked the validity of asm opcodes...I figured it would just generate an illegal instruction trap at runtime if the opcode wasn't supported.

[victorshoup]

@mr-c
Oops, my bad...the error "instruction requires: aes" must be coming from the assembler.
When I compile with -S, it does OK.

[victorshoup]

@mr-c
More info. Using g++-15 from homebrew...

If instead if -march=native I, use -mcpu=apple-m1+aes then BOTH versions of PCLMUL work: both my asm hack and the SIMDE code itself, and the ASM output is essentially identical.
And without the "_aes", neither version works.

So now I'm fundamentally confused about -march vs -mcpu... for years, I was just using -march=native on x86, and this was wonderful...no more worries about different ISAs... but I don't get what is happening on this ARM...

To add to the mystery, with Apple clang, it doesn't matter what I put...-march=native or nothing at all...everything works.
I guess that's because the apple compiler is set up to compile natively on this machine?

Also weirdly, with g++15, it recognizes FMA even without -march or -mpcu set...that also makes little sense to me.
Maybe g++15 is set up by default to compile a generic Arm64 which includes FMA, but not AES?
That would make sense...

Perusing the web, I found this...
https://community.arm.com/arm-community-blogs/b/tools-software-ides-blog/posts/compiler-flags-across-architectures-march-mtune-and-mcpu

It's a bit old, but based on that, it seems -mcpu=native on ARM should be the same as -march=native on x86.
This seems crazy to me...
But even then, it doesn't work as advertised...I mean, with g++15, -mcpu=native did not set the AES feature flag, and the PCLMUL code does not compile...

I'm not sure how to proceed, really...
It seems that if I want to support Apple Silicon, I have a working solution with my asm hack.
And maybe it can work in other environments, but users will have to figure out the right combination.

In any case, it seems like your FMA fix should work fine, so when that is rolled out in a new version of SIMDE, I'll have my code use that.
The PCLMUL nut looks harder to crack...

[victorshoup]

One more data point. Using apple clang...
I tried comping vmull_p64 directly.
With -march=native, I get function 'vmull_p64' requires target feature 'aes'
With -mcpu=native, it compiles
With -mcpu=apple-m1+aes, it compiles

If I compile my asm code, it works with any setting or -march and -mcpu, including none.
I'm not sure which if these results represents some sensible logic, and which are just bugs/inconsistencies in the toolchain