On 02/17/15 07:03, Richard Biener wrote:
This is something I noticed some time ago and that I remembered when
you added that looping SSA_NAME_VALUE to simplify_control_stmt_condition.
Currently DOM doesn't make sure that when setting
SSA_NAME_VALUE (x) = y that SSA_NAME_VALUE (y) == y, thus you could
get SSA_NAME_VALUE forming a chain until you reach the final value.
Thus the following patch which fixes all occurances and removes the
looping from simplify_control_stmt_condition. Did you have any
testcase when you added that looping?
pr61607, which probably looks familiar :-)
Note that this is purely by code inspection and I don't have any
testcase where a SSA_NAME_VALUE chain causes missed optimizations
(you'd have to disable a lot of other optimizations before dom1
to be able to create a reasonably simple one).
Anyway - the tree-ssa-dom.c part bootstrapped and tested ok on
x86_64-unknown-linux-gnu, the tree-ssa-threadedge.c part bootstrapped
ok ontop of that and testing is still in progress.
Ok?
Thanks,
Richard.
2015-02-17 Richard Biener <rguent...@suse.de>
* tree-ssa-dom.c (record_equivalences_from_phis): Valueize PHI arg.
(record_const_or_copy_1): Valueize y.
(record_equivalences_from_stmt): Valueize rhs.
* tree-ssa-threadedge.c (simplify_control_stmt_condition):
Remove repeated valueization.
Given the regression was fixed elsewhere, let's table this until gcc-6.
I want to rip out large hunks of this code, at least on the threading
side and replace it with a backwards walk similar to what Sebastian did
for the FSM optimization. As a nice side effect, that ought to
completely disentangle DOM and the threader.
At the same time I want to see what effect we'd have by disabling these
context sensitive propagations in DOM. They add a lot of hair and I'm
just not sure they're worth it. If we really need them, perhaps we can
get away with something simpler, outside of DOM.
jeff
