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
