On 10/21/13 06:19, Richard Biener wrote:
I wonder why this isn't part of the regular jump-threading code - after
all the opportunity is to thead to __builtin_unreachable () ;) Otherwise
the question is always where you'd place this pass and whether it
enables jump threading or CSE opportunities (that at least it does).
In theory one could do this as part of jump threading. Doing it in jump
threading would have the advantage that we could use a NULL generated in
a different block than the dereference. Of course, we'd have a full
path to duplicate at that point.
The downside is complexity. This pass is amazingly simple and
effective. The jump threading code is considerably more complex and
bolting this on the side would just make it worse.
From a pipeline location, if kept as a separate pass, it probably needs
to be between DOM1 & phi-only cprop. DOM1 does a reasonable job at
propagating the NULL values into the PHI nodes to expose the
optimization. And the pass tends to expose precisely the kinds of PHI
nodes that phi-only cprop can optimize. VRP2/PRE/DOM2 do a good job at
finding the newly exposed CSEs and jump threading opportunities.
I haven't looked to see if there's anything left to optimize after DOM2,
but I can certainly speculate that there would be cases exposed by the
various passes that currently exist between DOM1 & DOM2. That's
certainly worth exploring.
As you know, phase ordering will always be a concern. We already have
acknowledged that we're punting some of those issues once we stopped
iterating DOM.
Jeff
