Re: merging for 3.4 (was Re: [Patch] Qualify min(), max() ...)

[Jan Hubicka <hubicka at ucw dot cz>]

> Diego writes:
> 
> > Whether tree SSA can be merged for 3.4 will depend on the state
> > of the branch by the time the Stage 1 window closes.  We are
> > making rapid progress but I would like to have the following in
> > place:
> 
> [ stuff deleted ]
> 
> > - Performance issues.  Right now the code generated by the tree
> >   optimizers is worse than the RTL optimizers.  This is to be
> >   expected at this stage and the whole tree optimization process
> >   can be disabled.  So, in principle I don't see a real problem
> >   with merging the infrastructure in.
> 
> To me, this is critical.  GCC has, by some measures, slowly been getting
> worse and worse.  I believe in the tree-ssa concept, but I don't think

What measures do you have in a mind?  From the code performance point of
view situation don't seems to be so critical according to the SPEC
testers.  Perhaps in for other architectures than i386 or other tests it
is, but that just means that we need more periodic testers to keep
quality in control.
>From compile time performance point of view sitaution is different
tought :(.

Compiler is getting slower in each release but that is mostly cumulative
result of adding new features current infrastructure can't accept
cheaply...

I would like to see the reason for slowowns on SSA branch to be
understood and fixed before merging too.
On the other hand I would love to see merging to happen in 3.4 period as
too many things are getting dependent on the SSA work and we should keep
dependence chain small if possible.

Honza
> that it should be accepted until it is a clear win.  What happens in
> almost every case is that people know that a change makes things worse by 
> some measures, but they like the elegance and are sure they can fix it
> later.  Then it never gets fixed.  We can't force volunteers to do things,
> so the only control that we have is keeping things out of the compiler
> until they clearly improve it.
> 
> > I see two possible scenarios regarding optimization:
> > 
> > (a) We merge the infrastructure with the optimizers disabled and
> >     keep working on them in mainline.  This has the advantage of
> >     exposing the code for more testing, but it might disrupt
> >     development.
> > 
> > (b) We don't merge anything for 3.4, keep working on the branch
> >     and merge everything for 3.5 or whenever we close the
> >     performance gap.
> > 
> > Sometimes I'm more inclined towards (b), it seems safer.
> 
> Likewise.