This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]