Georg-Johann Lay wrote:
David Brown schrieb:
Georg-Johann Lay wrote:
As far as "the optimizer" of gcc is concerned, that makes no
difference. It knows exactly what register contains what value and
is aware of the place where a register "dies", i.e. the register can
be reused for whatever other stuff. Anyway, even if just one temp
variabe is used, gcc will produce a new (pseudo) register vor every
result like moves, arithmetic, etc. These pseudos may or may not end
up in the same macine register. On that level, blocks are just
syntactic sugar (if they are not used to hide visibility, e.g. like
in int tmp=0; {int tmp = 1;} )
I haven't looked at code generated for such switches (there is often
so much of it), so I admit to having guessed a little. I was thinking
especially of when you have debug information enabled - that can force
the compiler to keep variables in separate registers.
Are you really sure? As far as I know gcc produces the same code
No, I'm not sure in this case (as I said, I haven't checked it).
regardless if optimization is on or not. If fact I would guess that it
is a policy that the code *must* be the same regardless what debug level
(if any) or debug format is used, and code beeing dependent on debug
level/format is worth a bug report.
That is certainly not true. Enabling debug information will disable or
limit some optimisations. gcc in general is pretty good at optimising
code even when debugging is enabled (compared to many other compilers),
but debugging formats are limited and that limits the compiler. For
example, most debugging formats are happy with a local variable being
assigned to a register, but can't describe situations where the
variable's register moves around. Even the most sophisticated debugging
formats can't cope with transforms such as "for (x = 0; x < 10; x++)
..." being transformed into "x = 10; while (--x) ..." which will often
be smaller and faster.
To get a notion of the various machine intependant transformations,
have a glance at gcc's output with -fdump-tree-all, and for the
machine dependent it is -fdump-rtl all. They make clear that
do-while, while, for and if-goto are just flavours of same sugar.
And here was me thinking the generated source code was sometimes a bit
big to wade through... Sometime I must look at this in more detail.
Yes, of course, that example is much too complex. But for small
examples it is very interesting to track how gcc is transforming and
kneading and stiring the code again and again beyond recognition.
I was trying with a small example! But as you say, it is interesting to
look at this output, and I plan to do so for some code samples when I
get the chance - thanks for the tip on these flags.
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
