Re: My opinions on tree-level and RTL-level optimization

[Roger Sayle <roger at eyesopen dot com>]

On Sat, 16 Apr 2005, Richard Kenner wrote:
>     Although, RTL expansion may introduce new loops, these tend to be
>     rare, and the expanders have all the information they need to
>     hoist/sink invariant expressions and unroll/peel themselves.
>
> I disagree.  In order to make the proper decisions about merging givs
> and chosing which giv should represent a biv, you have to know a lot
> about the valid addressing modes on the machine and this isn't something
> the tree level optimizers should have to deal with.
> ...
>
>     Simiarly, CSE shouldn't need to process more than a single basic
>     blocks,
>
> Again, not clear.  Certainly the costly stuff I put in ages ago to
> walk through comparisons and around loops needs to go, but there's
> no reason to tie CSE to a basic block: it can operate until the next
> label, like it does now.  Admittedly, the number of CSE opportunities
> won't be great, but why restrict them to a basic block?
>
>     and GCSE shouldn't need to move anything other than simple
>     expressions.
>
> Why would we need a GCSE at the RTL level at all?  I'd guess the number
> of wins it would produce would be very small.
>
>     The quality of alias analysis at the RTL-level shouldn't be an issue.
>
> Here I disagree the strongest!  Instruction scheduling is rapidly
> becoming one of the most critical optimizations and must be done at
> the RTL level.  The quality of instruction scheduling depends quite
> heavily on the quality of the aliasing information.


Thanks for your feedback.  I agree with all your points.  I had
greatly underestimated the importance of RTL alias analysis, especially
with respect to scheduling.  The compile-time hog issues with CSE are
primarily due to deep path-following (AFAIU).  Simple/cheap tricks are
such as extended basic blocks are clearly a win, but their benefit depends
on whether we keep GCSE. If we don't then EBBs of course, if we do, the
EBBs are probably subsumed by GCSE.  And its very true at the RTL-level
addressing modes have always been an Achilles' heel.  But whilst
induction variable selection is very dependent upon target parameters,
as is prefetching, but it's not yet clear whether uglifying tree-ssa or
continuing to improve RTL loop analysis is the better long-term strategy.

I take it from your comments, that you are in the camp that believes
that "the sun has not yet set" on the need for RTL optimizers. :-)
The intent of my post was to defend what was seen as my pro-RTL
stance, it's interesting to see that the loudest feedback is that
I'm underestimating/down-playing the importance of the RTL optimizers.

Much appreciated,

Roger
--