[Bug rtl-optimization/90706] [9 Regression] Useless code generated for stack / register operations on AVR

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.3

[Bug rtl-optimization/90706] [9 Regression] Useless code generated for stack / register operations on AVR

[bseifert at gmx dot at]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706

--- Comment #3 from Berni  ---
There is no improvement with gcc 9.2.0

[Bug rtl-optimization/90706] [9 Regression] Useless code generated for stack / register operations on AVR

[bseifert at gmx dot at]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706

--- Comment #2 from Berni  ---
(In reply to Georg-Johann Lay from comment #1)
> (In reply to Berni from comment #0)
> > pushing r0 does not make sense at all since it is by definition a temporary
> > register that can freely be modified. Maybe it's just pushed to make room
> > for the stack operations?
> 
> Yes. 
> 
> The code from v8 is already suboptimal: It's nonsense to load R28 with 0x1
> just to survive a function call. Better use a call-used register and load it
> after the function call to where the return value is computed. Then there
> would be no need to push/pop R28.
> 
> Does -fno-caller-saves improve v9 code?
> 
> This is definitely not a target issue. It's likely a register-allocation
> problem. And the v8 problem is because some (tree) passes move setters away
> from their consumers.

With option -fno-caller-saves there is no change in v9 code!

[Bug rtl-optimization/90706] [9 Regression] Useless code generated for stack / register operations on AVR

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706

Georg-Johann Lay  changed:

   What|Removed |Added

  Component|target  |rtl-optimization
Summary|Useless code generated for  |[9 Regression] Useless code
   |stack / register operations |generated for stack /
   |on AVR  |register operations on AVR

--- Comment #1 from Georg-Johann Lay  ---
(In reply to Berni from comment #0)
> pushing r0 does not make sense at all since it is by definition a temporary
> register that can freely be modified. Maybe it's just pushed to make room
> for the stack operations?

Yes. 

The code from v8 is already suboptimal: It's nonsense to load R28 with 0x1 just
to survive a function call. Better use a call-used register and load it after
the function call to where the return value is computed. Then there would be no
need to push/pop R28.

Does -fno-caller-saves improve v9 code?

This is definitely not a target issue. It's likely a register-allocation
problem. And the v8 problem is because some (tree) passes move setters away
from their consumers.