AW: [avr-gcc-list] SIGNAL and INTERRUPT overhead

[Haase Bjoern (PT-BEU/EMT) *]

Benjamin Titzer wrote:

>>
>>Sounds to me like the design of GCC and the constraints of a particular
>>calling convention do not allow it to do something smart here. I think the
>>solution that would satisfy most everyone involved would be for the
>>compiler to generate code that only saves the state of registers that it
>>uses (and overwrites) and then restore them upon exit. This is a simple
>>use-def analysis on the registers and would be simple enough to implement.
>>  
>>
>I think that gcc optimizer does that, provided that it can get all the 
>information when compiling. If the
>interrupt handler calls an external function (external to the source 
>file), then the compiler is not able
>to know what to save and what not to save, so it saves everything.

Presently, GCC does not even track register usage of functions that are defined 
in the same module. IIUC, presently most of the inter-function optimizations 
are run on the tree level, so that no optimizations conerning register usage 
could be implemented right now. This includes all of the optimizations that 
exploit knowledge that is available only after register allocation.

>That's a big problem with the usual way of building code, with functions 
>or set of related functions in
>different files. When the compiler groks the files, it does not have all 
>the information that would help
>it build a much better optimized code.

IIUC, it would be sufficient to compile them at the same time. I.e. use gcc 
file1.c file2.c -o app.elf ...

>An as-optimizer would be very nice, and from what I've understood of 
>gcc, one could probably build
>such a tool by writing another front end for gcc (reading assembly 
>language) and then using all the
>optimization systems that are in the compiler.

You will probably have problems since you, e.g., do not know if a variable has 
been declared to be volatile. Also debugging would no longer be possible. Also 
you would have to find a way where some function is starting and where it is 
ending from the dissassembly. Nontrivial task.

Better way, IMO, would be to try to get better using the present compiler 
framework. This will require, IMO, to do the subreg lowering earlier than we 
are doing right now for avr (i.e. *before* the reload pass). I have the 
impression, that this will help most only if one could teach gcc for all 
targets to make some inter-function optimizations on the RTL level, so this 
latter thing is the issue, I think to be most important right now.

One possibly could try to make some other optimizations during linking: One 
then could, e.g., replace call instructions by rcall if the distance happens to 
fit.

Yours,

Björn