[PATCH] D129727: [ARM64EC 11/?] Add support for lowering variadic indirect calls.

Eli Friedman via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jul 14 10:04:03 PDT 2022


efriedma added inline comments.


================
Comment at: llvm/lib/Target/AArch64/AArch64FrameLowering.cpp:483
+    // But we don't know the function is variadic or not here.
+    // Not sure if we can align to 8 for normal exit thunk.
+    bool Arm64Ec = isArm64EcThunk(MF.getFunction());
----------------
For the whole "x3 is stored to the stack" thing, if we're going to continue to use an alloca, I'd probably recommend just increasing the size of the alloca by 8 bytes, then explicitly emit a store instruction in the IR.  Messing with the alignment like this seems likely to cause issues.


================
Comment at: llvm/test/CodeGen/AArch64/arm64ec-cfg.ll:363-365
+; CHECK-NEXT:    mov x8, sp
+; CHECK-NEXT:    sub x0, x8, x15, lsl #4
+; CHECK-NEXT:    mov sp, x0
----------------
bcl5980 wrote:
> It looks Microsoft generate codeļ¼š
> 
> ```
> sub         sp,sp,x15,lsl #4
> ```
> Does anyone know why we can't accept SP as input/ouput for the instruction?
> 
> ```
> def : Pat<(sub GPR64:$Rn, arith_shifted_reg64:$Rm),
>           (SUBSXrs GPR64:$Rn, arith_shifted_reg64:$Rm)>;
> ```
> 
> 
> 
The instruction used by the Microsoft compiler is SUBXrx64.  SUBSXrs can't refer to sp that way; the "lsl" is actually an alternate spelling of "uxtx".

We could add a specialized pattern specifically for subtraction operations where the first operand of the subtraction is a copy from sp.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129727/new/

https://reviews.llvm.org/D129727



More information about the llvm-commits mailing list