Bug 20296 - Speeding up small interrupts on avr
Summary: Speeding up small interrupts on avr
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.1.0
: P5 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
Keywords: missed-optimization
Depends on:
Reported: 2005-03-02 23:47 UTC by berndtrog
Modified: 2012-07-29 20:16 UTC (History)
6 users (show)

See Also:
Target: avr
Known to work:
Known to fail:
Last reconfirmed: 2005-11-26 01:35:32


Note You need to log in before you can comment on or make changes to this bug.
Description berndtrog 2005-03-02 23:47:47 UTC
When I compile (avr-gcc -Os -c -mmcu=at90s2313) this:

void SIG_PIN_CHANGE0 (void) __attribute__ ((signal)); void SIG_PIN_CHANGE0 (void)
  (*(volatile unsigned char *)((0x12) + 0x20)) |= 1;

I get:
00000000 <SIG_PIN_CHANGE0>:
   0:   1f 92           push    r1
   2:   0f 92           push    r0
   4:   0f b6           in      r0, 0x3f        ; 63
   6:   0f 92           push    r0
   8:   11 24           eor     r1, r1
   a:   90 9a           sbi     0x12, 0 ; 18
   c:   0f 90           pop     r0
   e:   0f be           out     0x3f, r0        ; 63
  10:   0f 90           pop     r0
  12:   1f 90           pop     r1
  14:   18 95           reti

If the optimizer?/backend knows that the 'sbi' instruction does not
 modify r1 or the status register (0x3f) it could generate this instead:
sbi 0x12, 0

Comment 1 Björn Haase 2005-03-04 19:51:20 UTC
IMHO everyone working on the avr back-end is aware of this problem. The 
difficulty is, that the present architecture of the avr back-end does not 
easily permit to improve this case: Every instruction pattern (like "multiply 
two 16 bit integers" or "sign-extend a 16 bit variable to 32 bits") presently 
is free to assume that may overwrite or change r0 and r1 unless it leaves the 
"__zero_reg__" with 0 after finishing it's task. 
Resolving this issue, IMHO, would require a major refactoring of the 
back-end. ... IIUC the keyword is "replace all of the more complex instruction 
patterns by RTL expressions." 
I suggest to mark this bug as "desired enhancement". 
Comment 2 Wim Lewis 2011-11-06 20:39:49 UTC
FWIW, confirming that versions 4.3.4 and 4.6.2 still emit these unnecessary saves of r0 and r1 for small ISRs (the generated code is identical to what berndtrog@yahoo.com posted, at least for optimization levels >= 1).