User account creation filtered due to spam.

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 posted, at least for optimization levels >= 1).