[Bug target/60300] [avr] Suboptimal stack pointer manipulation for frame setup

[Bug target/60300] [avr] Suboptimal stack pointer manipulation for frame setup

[matthijs at stdin dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60300

--- Comment #1 from Matthijs Kooijman <matthijs at stdin dot nl> ---
I noticed I didn't use -O in the output I pasted, but I just confirmed that the
results are the same with -Os and -O3.

[Bug target/60300] [avr] Suboptimal stack pointer manipulation for frame setup

[gjl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60300

Georg-Johann Lay <gjl at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |avr

--- Comment #2 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
AFAIK the code cares for reasonably fast execution, even when optimizing for
size.  This is because the code is for interrupt service routine (ISR)
prologue.  

RCALL is quite slow.

[Bug target/60300] [avr] Suboptimal stack pointer manipulation for frame setup

[matthijs at stdin dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60300

--- Comment #3 from Matthijs Kooijman <matthijs at stdin dot nl> ---
Hmm, I don't think the gcc sources support that. AFAICT, they attempt to just
find the shortest approach, without caring for speed. For example, look at
avr.c, around line 1265, where it says:

              /************ Use shortest method ************/

              emit_insn (get_sequence_length (sp_plus_insns)
                         < get_sequence_length (fp_plus_insns)
                         ? sp_plus_insns
                         : fp_plus_insns);

https://github.com/mirrors/gcc/blob/c2e306f5efb32b7eed856a1844487cff09aa86ac/gcc/config/avr/avr.c#L1265-L1270

[Bug target/60300] [avr] Suboptimal stack pointer manipulation for frame setup

[senthil_kumar.selvaraj at atmel dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60300

Senthil Kumar Selvaraj <senthil_kumar.selvaraj at atmel dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |senthil_kumar.selvaraj@atme
                   |                            |l.com

--- Comment #4 from Senthil Kumar Selvaraj <senthil_kumar.selvaraj at atmel dot com> ---
It doesn't actually get to that - avr_sp_immediate_operand returns false if the
operand is not IN_RANGE(-6,6). The comments are a bit misleading though - the
shortest sequence only applies if the addend is within that range.

Like Johann said, it must be a deliberate decision in favor of speed - the
attached program with a stub implementation of bar and main calling foo clocks
a couple of cycles lesser with DSIZE=7 than with DSIZE=6(as measured with
avrtest), although the code is 6 bytes longer. If RCALLs and PUSH had been
generated, the code would be 4 bytes shorter, but would need 4 more clock
cycles.