This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: proposal for compilation unil wide alias analyis
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: mark at codesourcery dot com
- Cc: gcc at gcc dot gnu dot org
- Date: Sat, 26 Jun 04 16:03:33 EDT
- Subject: Re: proposal for compilation unil wide alias analyis
In other words, I'd expect that having the tree-to-RTL expanders take
GENERIC -- or even near-generic with callbacks into the front end to
expand non-GENERIC bits to GENERIC on the fly -- would be a win over
forcing everything to be converted to SSA GIMPLE first. The fewer
passes we make over the tree structure, the better.
Do you mean GENERIC or GIMPLE here? I thought the idea was to make the RTL
expanders accept only GIMPLE. That will not only make them smaller but
perhaps faster. I agree about going into SSA, but I think the cost of going
all the way into GIMPLE is small and saving it isn't worth complicating the
RTL expanders. (Although it may not need to be "full GIMPLE": there's
no point in creating the temporary for (I + J) * K, for example, in -O0).
The Laffer curve argument (we can remove so much code in the
optimizers so quickly that generating the code will actually be
faster) seems to me like it is one that should be proven
experimentally before we commit to it.
I agree, but don't see it as a single issue: I see it as an independent
decision for a number of different optimizers.
(For reference, I've seen compilers that had two completely different
code generators: one for optimized code and one for unoptimized code.
They basically split after front end processing into completely
different bodies of code. The unoptimized code version was very dumb,
but very fast.)
GCC used to do this in part. We'd use a separate register allocator,
stupid.c, for the -O0 case. This was eliminated in GCC 3 and we took a
substantial hit on -O0 compilation speed as a result.