On 2/11/22 07:35, Richard Sandiford wrote:
Dan Li <ashim...@linux.alibaba.com> writes:
On 2/11/22 01:53, Richard Sandiford wrote:
Dan Li <ashim...@linux.alibaba.com> writes:
On 2/10/22 01:55, Richard Sandiford wrote:
void f();
int g(int x) {
if (x == 0) {
__asm__ ("":::"x19", "x20");
return 1;
}
f();
return 2;
}
Then it seems X30 is treat as a "component" (the test
result of aarch64.exp also seems fine).
g:
stp x19, x20, [sp, -32]!
cbnz w0, .L2
mov w0, 1
ldp x19, x20, [sp], 32
ret
.L2:
str x30, [sp, 16]
bl f
ldr x30, [sp, 16]
mov w0, 2
ldp x19, x20, [sp], 32
ret
And I think maybe we could handle this through three patches:
1.Keep current patch (a V5) unchanged for scs.
2.Add shrink-warpping for X30:
logically this might be a separate topic, and I think more testing
might be needed here (Well, I'm a little worried about if there might
be other effects, since I just read this part of the code roughly
yesterday).
3.Add scs push/pop to shrink-wrapping (and maybe we can do the same for
the PAC code in pro/epilogue, since it's also the operation of the X30).
Yeah, that's fair.
(Like I said earlier, I wasn't asking for the shrink-wrapping change.
It was just a note in passing. But as you point out, the individual
shrink-wrapping support would be even more work than I'd imagined.)
Hi, Richard,
As said before, I try to enable R30 as component[1] in
shrink-wrapping separate.
The test results of this patch in x86-64 native compile/aarch64
cross-compile are consistent with the mainline (but there are
still few use cases not working properly in my test environment).
please let me know if I'm missing something :)
[1] https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590906.html
