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

[Bernard Fouché]

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.

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.

My wish would be to have a tool that disassembles some elf file (there 
is obj-dump, so that's okay) and
re-optimize the assembly flile and then send it to as(1) to make a new, 
better optimized final file.
(I've heard about only a single company makes such tools, and they do 
not support avr)

In this way, beside calls to external function (say 'system' functions), 
the resulting code would be shorter
(for instance by inlining all functions called only once) and faster 
(just by removing unnecessary push/pops)
and at last the optimizer would have everything at hand.

Until this, I made a few scripts that help me build a single C file from 
many differents, and I manually
find functions called only once to have them prefixed by something that 
ccp changes to 'static inline' when
the project is built to produce the final 'big C file'.

(I did not find a gcc option to tell it that all functions are 'static' 
nor I found one to tell it to
automatically inline functions called only once.)

Working that way, and then checking in the final .lss file everything 
that was included by the linker to
remove things that could be, I got an 8% size reduction on a booloader. 
However I spent a whole
day setting all this things all right.

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.

 Bernard