Re: [PATCH][RFT] Optimization pass-pipeline re-organization [3/n]

[Jeff Law <law at redhat dot com>]

Richard Guenther wrote:

> > the redundancy elimination performed by DOM can be better handled elsewhere.
> > The interesting question is there redundancy elimination left in DOM that is
> > unique and if not, can we get the same overall effect if we remove the
> > redundancy elimination from DOM and instead using existing passes for
> > redundancy elimination.  Same overall effect doesn't mean identical code, but
>
> ... though I am not sure (I didn't investigate) how much of the
> redundancy elimination code feeds the jump threading parts.  I was
> thinking of moving the jump threading parts over to SCCVN instead, given
> that VRP lacks capabilities regarding to symbolical conditions.
It's reasonably common.  At one time I had mostly convinced myself that 
fixing PRE was the way to go as many of the complex threading cases 
would be much simpler if PRE was more effective at removing partial 
redundancies.

But the more I pondered the problem the more I realized that the 
frameworks we have simply weren't sufficient to solve the class of 
problems I wanted to look at.

In fact, there was a master's thesis (don't have it handy right now) 
which argued that what we're doing (poorly) in DOM is actually a whole 
new class of context/path specific optimizations and that solving them 
with traditional techniques was ultimately a horrid compile-time sink.

They came up with a new framework to perform these context/path 
sensitive optimizations, but I wasn't ever able to wrap my head around 
it well enough to understand or explain it.  In essence it was a 
context/path sensitive PRE-like algorithm.  It looked expensive, but far 
less so than running multiple passes of our iterating DOM optimizer.


> Thanks.  It seems the last DOM pass doesn't do very much as well, so
> I'll be playing with removing that as a last step of cleaning up the
> pipeline.  Even if that might need another run of FRE instead of DOM.
One of the indicators to watch is whether or not the RTL jump threading 
code starts to become more important -- if it does, then we're ripping 
too much out of DOM.

When I last looked, the only common case left where the RTL version was 
still useful were cases where our tree aliasing code sucked horribly bad 
 causing DOM/PRE to miss stuff which we later caught in the RTL jump 
threading code.

jeff