* [Bug target/60300] [avr] Suboptimal stack pointer manipulation for frame setup
[not found] <bug-60300-4@http.gcc.gnu.org/bugzilla/>
@ 2014-02-21 17:56 ` matthijs at stdin dot nl
2014-04-07 13:33 ` gjl at gcc dot gnu.org
` (2 subsequent siblings)
3 siblings, 0 replies; 4+ messages in thread
From: matthijs at stdin dot nl @ 2014-02-21 17:56 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 4+ messages in thread* [Bug target/60300] [avr] Suboptimal stack pointer manipulation for frame setup
[not found] <bug-60300-4@http.gcc.gnu.org/bugzilla/>
2014-02-21 17:56 ` [Bug target/60300] [avr] Suboptimal stack pointer manipulation for frame setup matthijs at stdin dot nl
@ 2014-04-07 13:33 ` gjl at gcc dot gnu.org
2014-04-08 13:09 ` matthijs at stdin dot nl
2014-05-12 13:30 ` senthil_kumar.selvaraj at atmel dot com
3 siblings, 0 replies; 4+ messages in thread
From: gjl at gcc dot gnu.org @ 2014-04-07 13:33 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 4+ messages in thread* [Bug target/60300] [avr] Suboptimal stack pointer manipulation for frame setup
[not found] <bug-60300-4@http.gcc.gnu.org/bugzilla/>
2014-02-21 17:56 ` [Bug target/60300] [avr] Suboptimal stack pointer manipulation for frame setup matthijs at stdin dot nl
2014-04-07 13:33 ` gjl at gcc dot gnu.org
@ 2014-04-08 13:09 ` matthijs at stdin dot nl
2014-05-12 13:30 ` senthil_kumar.selvaraj at atmel dot com
3 siblings, 0 replies; 4+ messages in thread
From: matthijs at stdin dot nl @ 2014-04-08 13:09 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 4+ messages in thread* [Bug target/60300] [avr] Suboptimal stack pointer manipulation for frame setup
[not found] <bug-60300-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2014-04-08 13:09 ` matthijs at stdin dot nl
@ 2014-05-12 13:30 ` senthil_kumar.selvaraj at atmel dot com
3 siblings, 0 replies; 4+ messages in thread
From: senthil_kumar.selvaraj at atmel dot com @ 2014-05-12 13:30 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 4+ messages in thread