Re: [PATCH] Improve DOM's optimization of control statements

[Renlin Li <renlin.li@arm.com>]

Hi Jeff,

Your patch causes an ICE regression.
The test case is " gcc.c-torture/compile/pr27087.c", I observed it on 
aarch64-none-elf target when compiling the test case with '-Os' flag.

A quick check shows, the cfg has been changed, but the loop information 
is not updated. Thus the information about the number of basic block in 
a loop is not reliable.

Could you please have a look?

Regards,
Renlin

On 30/09/15 21:28, Jeff Law wrote:
> 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