Re: [avr-gcc-list] Gcc branches small comparison.

[Curtis Maloney]

Bruce D. Lightner wrote:
> Dmitry K. wrote:
> > Results are in form: prog_words + stack_bytes
> >
> > -mmcu=atmega8 -Os -frename-registers
> >                 3.2.3   3.3.5   3.4.3   4.0     4.0-nrr
> >
> > bsearch          69+12   68+12   67+12   66+12   66+12
> > free             99+2    92+2    92+2    86+2    86+2
> > qsort           464+22  450+22  450+22  412+22  412+22
> The results for 4.0 clearly suck!  These are big differences for 
> microcontrollers with very limited memory space.  Can you explain what 
> is going on?

Well, those 3, at least, have improved - qsort quite considerably.  So, it's 
not all bad.  I suspect part of the problem is in the migration to the new 
tree-ssa branch, and migrating all the old optimisations across.  Also, there 
has been considerable noise on the gcc mailing list about "fixing" the 
register allocator code.

> Or, am I being stupid assuming that things will *always* get better as 
> time goes on?

Given the GCC people consider "substantial reduction in code quality" to be a 
regression, no, thinks ought to always get better.  But sometimes they'll make 
sacrifices on the few for the good of the many...

> Maybe things like "Moore's Law" are setting unrealistic expectations for 
> those of us in this business.  Is the Second Law of Thermodynamics 
> affecting "gcc" development?  Is ever increasing entropy is somehow 
> negatively affecting "gcc" source code tree! :-)

I don't see what a law about the rate of increase in cost effective transistor 
densities has to do with this... although, perhaps it's all the result of some 
emergent complexity? ;)

Chin up - from what I've been reading on the gcc mailing list, there's good 
news on the way.

(And yes, I've been somewhat non-plussed by some of the code GCC is 
generating, ESPECIALLY with respect to longs).

--
Curtis Maloney.