This is the mail archive of the
mailing list for the libstdc++ project.
Re: merging for 3.4 (was Re: [Patch] Qualify min(), max() ...)
- From: Joe Buck <jbuck at synopsys dot com>
- To: dnovillo at redhat dot com (Diego Novillo)
- Cc: mark at codesourcery dot com (Mark Mitchell), bkoz at redhat dot com (Benjamin Kosnik), gdr at integrable-solutions dot net (Gabriel Dos Reis), pcarlini at unitus dot it (pcarlini at unitus dot it), libstdc++ at gcc dot gnu dot org (libstdc++ at gcc dot gnu dot org), gcc at gcc dot gnu dot org
- Date: Wed, 4 Dec 2002 12:54:37 -0800 (PST)
- Subject: Re: merging for 3.4 (was Re: [Patch] Qualify min(), max() ...)
> 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
[ 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
> (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.