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
