https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87627
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2018-10-17 00:00:00 |2021-8-19
--- Comment #7 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87627
--- Comment #6 from Alexander Monakov ---
FWIW the following CSE enhancement cleans this up, but I'm unhappy with this
patch because it's too narrowly targeted; in particular, won't clean up
void g(int a, int *b, int c);
void f(int a, int *b,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87627
--- Comment #5 from Alexander Monakov ---
I've spent some time looking at this again, and I couldn't find a way to
preserve REG_EQUIV notes (it's actually unclear what REG_EQUIV means
precisely).
What I think could help in simple cases like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87627
--- Comment #4 from Rich Felker ---
Thanks, that's helpful!
For 64-bit what I mean is that it emits:
pushq %r12
movl %edx, %r12d
pushq %rbp
movl %esi, %ebp
pushq %rbx
movl %edi, %ebx
call bar
movl %r12d, %edx
movl %ebp, %esi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87627
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87627
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87627
--- Comment #2 from Rich Felker ---
Further trial-and-error shows that it seems to be the sibcall itself that
causes the mess. My first guess is that something in the RTL considers the
whole argument area as clobbered/belonging to the sibcallee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87627
--- Comment #1 from Rich Felker ---
Results are similarly bad for 64-bit, except at -Os where it effectively just
pushes/pops the argument registers around the call to bar rather than
allocating call-saved registers for them. Using -Os on 32-bit
