Jorgen Lundman

I only went that way, as we (Solaris) started with `ia32/asm_linkage.h` - so I assumed it was the ZFS style. But then, the SIMD files are done with `simd_aarch64.h` so...

Starting to get a hang of the higher level of the blake3 work here, with the "stack" and pushing out work. Isn't this something that in ZFS would have traditionally...

Yep, skip over that extra, I'll handle that separately.

I'd be curious to test and see if this is related to the aarch64 on macOS issues.

I wonder if `CC_AArch64Apple` ever landed in llvm and I can use it for this as well.

Excellent, I will give it a go on macOS and Windows.

macOS changes to compile: https://github.com/openzfsonosx/openzfs-fork/commit/df3931c27302acbe2f59a0b9e72d5e474566e968 The `FN_NAME` fix is a quick hack, we should discuss that sometime. ``` # sysctl kstat.zfs.darwin.tunable.icp_gcm_impl=sse4_1 kstat.zfs.darwin.tunable.icp_gcm_impl: cycle [fastest] sse4_1 generic pclmulqdq -> cycle fastest...

Oh I assumed it was because `r11` is NULL, and ` addq 0x6, %r11` would dereference it, but I admit, I didn't stop and think if it even did dereference

> That should read 0x10, not 0x06 (`$16` in the code, so maybe the `1` got lost?). No it really is gone: ` add $16, \DATA_OFFSET ` ``` # llvm-objdump...

More on panic ``` panic panic(cpu 1 caller 0xffffff800dd69aef): Kernel trap at 0xffffff7f91292911, type 14=page fault, registers: CR0: 0x0000000080010033, CR2: 0x0000000000000010, CR3: 0x0000000011a69000, CR4: 0x00000000003606e0 RAX: 0xffffff7f9135adf0, RBX: 0xffffff90b0094ae8, RCX:...