Re: [PATCH][4/n] Remove GENERIC stmt combining from SCCVN

[Jeff Law <law at redhat dot com>]

On 06/29/2015 04:02 AM, Richard Biener wrote:
> Ok, the above isn't the correct place (seems to be used from the
> threading machinery only), but record_equivalences_from_incoming_edge is
> and that is where the special-case you mention is which handles
> widening converts but not sign-changes.  And yes, it's the wrong-way
> around, handling
But the threading machinery is where we need this code for the calloc.C 
test.

Conceptually DOM can only exploit an equivalence that dominates other 
statements.  In this case n_5/n_4 == 0 only reaches BB12 through one 
edge (BB5->BB12).   The equivalence doesn't hold on other paths (through 
BB11) into BB12.  Thus the equivalence isn't going to be recorded by 
r_e_f_i_e.

Jump threading on the other hand can use equivalences that are path 
specific without the dominance relationship -- but it only uses them to 
simplify conditionals.  Again, with limited digging, it appears we just 
need to add the code to handle this case for threading and the right 
things ought to happen.

Now if we did path duplication/isolation in DOM like we do in the 
threader, then we could optimize this case in DOM.  Basically we'd 
duplicate BB12.  One copy would be reachable via BB5, the other via 
BB11.  And magically the n_5/n_4 == 0 equivalence carries because it 
would dominate one of hte two copies.

The path duplication to expose redundancies is one of the things I'd 
like to get out of a Bodik-esque scheme.  One of the things Bodik's work 
does is identify the minimal set of blocks that need to be copied to 
expose each path specific redundancy that it finds.

Jeff