This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
merging for 3.4 (was Re: [Patch] Qualify min(), max() ...)
- From: Diego Novillo <dnovillo at redhat dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: Benjamin Kosnik <bkoz at redhat dot com>, Gabriel Dos Reis <gdr at integrable-solutions dot net>, "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 14:41:10 -0500
- Subject: merging for 3.4 (was Re: [Patch] Qualify min(), max() ...)
- Organization: Red Hat Canada
- References: <20021204102528.75c8b5cc.bkoz@redhat.com> <46020000.1039019892@warlock.codesourcery.com>
On Wed, 04 Dec 2002, Mark Mitchell wrote:
> After that, I expect the sequence you said: BIB->mainline, the new
> C++ parser, and then (perhaps) some tree optimizer stuff, although
> I haven't really gotten the impression that stuff is fully ready yet.
>
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:
- At least two front ends working. We already have C and it
looks like C++ is getting there.
- General acceptance for GENERIC and GIMPLE. GENERIC will impact
all the front ends, as we need every front end to emit GENERIC
so that it can then be converted into GIMPLE, which is the IL
that all the tree optimizers operate on.
Of course, a front end need only be converted to GENERIC if it
wants to use the tree optimizers, otherwise they don't need to
be modified at all.
- 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.
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.
Diego.