Until now DOM has had to be very conservative with handling control
statements with known conditions. This as been an unfortunate side
effect of the interaction between removing edges and recycling names via
the SSA_NAME manager.
Essentially DOM would have to leave control statements alone. So you'd
see stuff like
if (0 == 0)
left around by DOM. The jump threader would thankfully come along and
optimize that as a jump thread. But that's terribly inefficient, not to
mention it creates unnecessary churn in the CFG and SSA_NAMEs.
By optimizing that directly in DOM, including removing whatever edges
are not executable, we no longer have to rely on jump threading to
handle that case. Less churn in the CFG & SSA_NAMEs. There's also
some chance for secondary optimizations with fewer edges left in the CFG
for DOM to consider.
Unfortunately, the churn caused by jump threading made it excessively
difficult to analyze before/after dumps. Sadly, you can have the same
code, but if the SSA_NAMEs have changed, that impacts coalescing as we
leave SSA. Churn in the CFG changes labels/jumps, often without
changing the actual structure, etc.
I did some tests with valgrind to evaluate branching behaviour
before/after effects on the resulting code and those effects were tiny,
in the I doubt you could measure them range. That was expected since
what we're really doing here is just capturing the optimization earlier.
I had a couple more tests, but they were lost in a bit of idiocy. The
test included is the one I had a second copy of lying around.
Bootstrapped and regression tested on x86_64-linux-gnu. Installed on
the trunk.
Jeff