Unfortunately you appear to have little clue what you are really
talking about. So let me provide you with some loud feedback as well.
Please try to keep this discussion on a civil level!
> I had greatly underestimated the importance of RTL alias analysis,
> especially with respect to scheduling.
Which does not mean RTL alias analysis is important. It just means
that having alias information available in RTL is important. How you
get that information there is a separate issue.
I think Roger simply mis-spoke because in his original message, he
said what you said: the important issue is having the alias
information available in RTL. Much (but not all: eg., SUBREG info) of
that information is best imported down from the tree level.
You seem to have a misguided view on what CSE does. What we call CSE
is not a common subexpression elimination pass. It just happens to
catch some CSEs as well, but the most important thing it does right
now is propagation things forward to select better addressing modes
(essentially a kind of instruction selection), and limited
folding/simplifying to clean up the sometimes terrible things 'expand'
can do.
This is a very inaccurate characterization of CSE. Yes, it does those
things, but eliminating common subexpressions is indeed the major task
it performs.
(Kenner mentioned CSE around loops, but that is already gone.)
Sorry. But that is the cheaper of the two kludges (and I'm allowed to use
that word since I wrote them).
I agree that some of the details of the machine-dependent parts of the
tree optimizers are not the most elegant.
I think there's a serious conceptual issue in making the tree level too
machine-dependent. The *whole point* of doing tree-level optimizations
is to do machine-*independent* optimizations. Trees are machine-independent
and RTL is machine-dependent. If we go too far away from that, I think
we miss the point.
Besides, the RTL optimizers are not exactly a part of GCC to be proud
of if "ugliness" is a measure.
Really?
Of course GCC will always need a low-level IR. But, combine is
instruction selection in the worst possible way;
It served GCC well for decades, so I hardly think that's a fair statement.
reload is register allocation in the worst possible way,
Reload is not supposed to do register allocation. To the extent that
it does, I agree with you. But what this has to do with the issue of
tree vs. RTL optimization is something I don't follow. Surely you
aren't suggesting doing register allocation at the tree level?
