Grant Edwards wrote:
On 2007-02-15, David Brown <[email protected]> wrote:
I've noticed that msp430-gcc 3.2.3 often generates
unnecessarily large frame sizes?
<snip>
Can you post some compilable code that demonstrates these issues?
I'm trying.
I think part of the recipe might be to allow one or two cases
to fall through to the next one on the page, and throw in a
goto or three for exception handling. I may have inadvertently
defeated the compilers flow analysis by being overly "clever".
That's possible - I didn't try that. I generally try to avoid
fall-throughs in switches (except for multiple case labels with
completely identical handlers). I prefer to write it out explicitly,
and rely on the optimiser to avoid the duplication of code.
I haven't been able to reproduce them with simple test code -
Neither have I. :(
in every case, independent branches have re-used stack and/or
register space for local variables, regardless of optimisation
level.
You will find that for complicated code, the optimisation setting will
make a difference - higher levels run more analysis routines and are
therefore better at figuring out which code paths are independent, but
may also use more space (stack or registers) to track temporary
calculated data or to combine stack pointer manipulations.
In my experience, there is no point in ever compiling without at least
-O1. The code generated at -O0 is far less readable, and therefore less
useful for debugging, and you lose much of the compiler's warning
abilities. There is no such thing as code that only runs correctly when
compiled without optimisation, so there is very rarely use for it
(except for testing like this).
I finally settled on -O1. It generates the smallest frame sizes
(about 25% smaller than -O2) with almost no code size penalty
compared to -O2. Frame sizes blow up pretty badly using -O3
because functions that are only called once are get inlined.
This should only be the case if you have, as you say, been overly clever
and confused the code flow analysis. Otherwise things will work out
much the same even if some functions are inlined - the increase in frame
size in the calling function is offset by avoiding a new frame when the
function is called. The frame size should be the maximum of the space
needed for the different branches, rather than the sum, so you are only
going to waste significant space if you have a large frame function that
is inlined, while other branches call large frame functions. You can
always get around this sort of thing by using the "noinline" function
attribute - it is better to be explicit in your source code than relying
on the compiler flags chosen when compiling.
mvh.,
David
