Re: [avr-gcc-list] Re: C vs. assembly performance

[Georg-Johann Lay]

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 
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.

> > 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.

Georg-Johann