haberman wrote: To expand on my previous message, it appears that while this PR greatly improved the case of calling a normal function, it actually slightly pessimized the case where we are calling a `preserve_most` function.
Test case (https://godbolt.org/z/b4sc8T3v7) ```cc #ifndef CC #define CC __attribute__((preserve_none)) #endif __attribute__((preserve_most)) void NonTailCallFunc(long a, long b); CC long Next(long a, long b, long c, long d, long e, long f); CC long Func(long a, long b, long c, long d, long e, long f) { NonTailCallFunc(a, b); [[clang::musttail]] return Next(a, b, c, d, e, f); } ``` Results with normal calling convention: ```asm Func: push rax call NonTailCallFunc@PLT pop rax jmp Next@PLT ``` Results with `preserve_none` after this PR: ```asm Func: push rax mov rax, rsi mov rcx, rdi mov rdi, r12 mov rsi, r13 call NonTailCallFunc@PLT mov rdi, rcx mov rsi, rax pop rax jmp Next@PLT ``` Note that Clang had to preserve `rdi` and `rsi`, because they now store parameters `e` and `f` in `preserve_none`, but they store parameters `a` and `b` in `preserve_most`. If `preserve_none` used my suggested ordering (R12, R13, R14, R15, R11, R9, R8, RCX, RDX, RSI, RDI, RAX), there would be no overlap, because `rdi` and `rsi` are not used for arguments unless the function has 10 or 11 parameters. This ordering would therefore greatly reduce the chance of overlap compared with the existing ordering. https://github.com/llvm/llvm-project/pull/88333 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
