https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81987
Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wschmidt at gcc dot gnu.org --- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> --- It looks like the SLSR issue is latent before the change. The change introduces IL differences in PRE: <bb 11> [54.69%] [count: INV]: - # prephitmp_66 = PHI <d.6_6(9), prephitmp_104(10), pretmp_105(30)> - pretmp_117 = _2; - pretmp_116 = c.0_1; + # prephitmp_72 = PHI <d.6_6(9), prephitmp_112(10), pretmp_113(33)> + # prephitmp_73 = PHI <c.0_1(9), c.0_1(10), c.0_1(33)> + # prephitmp_74 = PHI <_2(9), _2(10), _2(33)> the first CFG difference appears after VRP1 where we see a predecessor edge order difference. --- a/t.c.104t.vrp1 2017-08-28 11:14:39.031605121 +0200 +++ b/t.c.104t.vrp1 2017-08-28 11:14:33.247510516 +0200 @@ -294,10 +294,10 @@ ;; 7 ;; basic block 7, loop depth 0 -;; pred: 28 -;; 6 +;; pred: 6 +;; 28 ;; 5 - # .MEM_60 = PHI <.MEM_57(28), .MEM_59(6), .MEM_39(5)> + # .MEM_60 = PHI <.MEM_59(6), .MEM_57(28), .MEM_39(5)> # VUSE <.MEM_60> # rhs access alignment 16+0 d.6_6 = d; That's expected given we change the order we install edges in split_edge. The PRE IL change is also somewhat expected as it uses post-order on the inverted graph to compute ANTIC_IN and this order is dependent on the order of edges in pred. I will poke a bit to see why there's a difference in what PRE finally does. So Bill - can you look at the SLSR issue?