Bug 48429 - ARM __attribute__((interrupt("FIQ"))) not optimizing register allocation
Summary: ARM __attribute__((interrupt("FIQ"))) not optimizing register allocation
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.4.5
: P4 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: missed-optimization
Depends on:
Blocks:
 
Reported: 2011-04-03 21:46 UTC by Shachar Shemesh
Modified: 2019-05-08 09:02 UTC (History)
1 user (show)

See Also:
Host:
Target: arm
Build:
Known to work:
Known to fail: 4.4.5, 4.5.2, 4.6.0
Last reconfirmed: 2011-06-09 10:39:47


Attachments
Source, intermediate and object code demonstrating the problem (1.92 KB, application/x-gtar)
2011-04-03 21:46 UTC, Shachar Shemesh
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Shachar Shemesh 2011-04-03 21:46:26 UTC
Created attachment 23866 [details]
Source, intermediate and object code demonstrating the problem

On ARM (at least for ARM966, which is the platform for which this GCC was compiled), fast interrupt queue, or FIQ, has a private copy of registers r8 through r14, and those do not need to be saved if used by the interrupt service routine.

When creating an interrupt handler, GCC is obviously aware of this fact, as it does not save the frame pointer at the beginning of the function (which it does if a different type of interrupt is requested). It still, however, begin allocation of registers from r2 and r3, and that forces it to save them at the beginning of the function. Beginning the allocation at r8 and r9 would have saved all register saving, and made the function more efficient.

Problem happens even when compiled with -O3. Function in attachment could have easily been implemented without the need for either save or restore of any registers at all.

Shachar
Comment 1 Ramana Radhakrishnan 2011-06-09 10:39:47 UTC
Confirmed.
Comment 2 Sven 2019-05-08 00:10:33 UTC
Even 8 years later, this bug is not fixed (gcc 8.3). I believe clang/llvm has the same problem.

Anyhow, that's not the only problem. The moment that a function is called, registers r0 to r3 (and maybe others) have to be saved. Then again, you probably don't call a function in your FIQ since you want it to be fast.

With the help of gcc's generated assembly, I write my FIQ handler in assembler. I don't mind, but fixing this would be very convenient.
Comment 3 Richard Earnshaw 2019-05-08 09:02:33 UTC
This is a missed optimization, not a bug.  Given that we have many more pressing issues it is unlikely to be addressed soon.

Of course, patches are always welcome...