[Bug tree-optimization/61452] [4.8/4.9/4.10 Regression] hang at -O1 and -Os on x86_64-linux-gnu

["rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61452

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Setting value number of f.7_12 to f.7_21 (changed)
Setting value number of g_18 to g_10 (changed)
Setting value number of f.7_12 to e.1_6 (changed)
Setting value number of g_18 to _13 (changed)
Setting value number of f.7_12 to f.7_21 (changed)
Setting value number of g_18 to g_10 (changed)
Setting value number of f.7_12 to e.1_6 (changed)
Setting value number of g_18 to _13 (changed)
Setting value number of f.7_12 to f.7_21 (changed)
Setting value number of g_18 to g_10 (changed)
Setting value number of f.7_12 to e.1_6 (changed)
Setting value number of g_18 to _13 (changed)
Setting value number of f.7_12 to f.7_21 (changed)
Setting value number of g_18 to g_10 (changed)
Setting value number of f.7_12 to e.1_6 (changed)
Setting value number of g_18 to _13 (changed)
...

e.1_6 is a "better" leader for f.7_12.

Ok, one reason is that even though we don't change the lattice value
of the PHI g_1 = PHI <g_10, g_18> from g_1 (varying) to g_10 in the
7th (for example) iteration we _do_ adjust its ->expr and thus simplify
expressions differently.  That's of course a no-no, if the lattice
value doesn't change it may really not change.

The whole dance visit_phi does with trying to set ->expr and ->has_constants
when it figured out a leader is pointless anyway - those are only relevant
for VARYINGs (in which case they are bogus).