Consider the following (https://godbolt.org/z/7frq7xM1Y)

void f(double g(double)) { g(1); }

Compile with --target=arm64ec-windows-msvc -O2 -fstack-protector-all. The relevant bit is the following:

[...]
        adrp    x8, __os_arm64x_check_icall
        ldr     x8, [x8, :lo12:__os_arm64x_check_icall]
        blr     x8
.Ltmp2:
        adrp    x8, __security_cookie
        ldr     x9, [sp, #8]
        ldr     x8, [x8, :lo12:__security_cookie]
        cmp     x8, x9
        b.ne    .LBB0_2
// %bb.1:
        fmov    d0, #1.00000000
        .seh_startepilogue
        ldr     x30, [sp, #16]                  // 8-byte Folded Reload
        .seh_save_reg   x30, 16
        add     sp, sp, #32
        .seh_stackalloc 32
        .seh_endepilogue
        br      x11
[...]

The stack protector check clobbers x9, which contains the callee address.

This was caused by e1e1836 , but it's not really the fault of that patch; AArch64Arm64ECCallLowering doesn't correctly pass x9 from __os_arm64x_check_icall to the call, so the register allocator isn't aware of the usage. That's theoretically easy to correct, but transforming an arbitrary call instruction is a bit painful... I'm planning to work on this, but it might take me a little while to put together a patch.

CC @cjacek @mstorsjo @dpaoliello @omjavaid