This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Project RABLET
On 6/24/06, Andrew MacLeod <amacleod@redhat.com> wrote:
On Fri, 2006-06-23 at 15:07 -0700, Ian Lance Taylor wrote:
> You omitted the RTL loop optimizer passes, which still do quite a bit
> of work despite the tree-ssa loop passes. Also if-conversion and some
> minor passes, though they are less relevant.
Which brings up a good discussion. I presume the rtl loop optimizers see
things exposed by addressing modes which aren't seen in the higher level
code. I wonder what the "big gains" are here...
Knowning which address computations are loop invariant. Knowing the
number of instructions (sadly not the exact size because instructions
haven't been selected) to determine whether it is worth
unrolling/peeling/unswitching a loop. Finding loops that can use a
doloop pattern.
and if they are
detectable at expansion time...
For most of them, I don't think so.
In general, I didnt mention anything that tends not to increase register
pressure, at least not in any significant manner as far as RABLET is
concerned.
So do you have hard data showing that CSE increases register pressure?
Given the thinks CSE does, it would probably be much more useful,
then, to make it possible to have liveness information in CSE so that
it can take register pressure into account in its cost considerations
;-) No magic new expand is going to make CSE obsolete, and it simply
does too much to just throw it out. (FWIW I'm still working on
simplifying cse.c...)
Clearly there will be a lot of further investigation required once
implementation reaches this point. Ultimately CSE and all RTL
optimizations can be re-evaluated to see if things can be simplified.
*laughs*
Every time some RTL optimizer is re-re-re-re-re-evaluated, it turns
out we lose without it. Good luck to you, but I think you're seriously
underestimating the complexity of things here.
> Modulo the above comments, I don't see anything wrong with your basic
> idea. But I also wonder whether you couldn't get a similar effect by
> forcing instruction selection to occur before register allocation. If
> that is done well, reload will have much less work to do.
Hurray.
This is what new-ra did. It was probably the only thing there that
worked well, but it was a great idea. (Sadly it was just reload
rewritten so pre-reload.c was ugly, but the idea was good).
Its clearly not as good as a new register allocator would be, but the
effort to benefit ratio ought to be a lot higher for RABLET than for a
register allocator rewrite.
There is a register allocator rewrite under way, from one of your
co-workers even. Is there any relation between Vlad's project and
yours, or are you going different ways with the same goal in mind? :-D
Gr.
Steven