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

[David Brown]

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.