https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52563
--- Comment #18 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 20 May 2016, andre.simoesdiasvieira at arm dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52563 > > --- Comment #17 from Andre Vieira <andre.simoesdiasvieira at arm dot com> --- > Ah yes my bad, its not sccp doing it... got a bit confused there... It is > indeed sink that moves that sequence down. Sorry for the noise. > > Question remains on how to clean this up though. Ideally you would like to end > up with > > a_p = <last_computed_base>; > outside of the loop. First of all please open a new bug for the FAILs. Second, the fix will be mostly adjusting the testcase expectations (eventually disabling LIM for example if we want to test SCCP abilities). As to your question it techincally is a job of CSE though it may be a tough job to make it figure out the equivalence. Now, in the case of scev-5.c (the only regression I see on x86_64, with -m32), SCCP fails to do final value replacement for i_24: <bb 4>: # i_12 = PHI <i_10(3), i_9(5)> MEM[(int *)&a][i_12] = 100; i_9 = i_5 + i_12; if (i_9 <= 999) goto <bb 5>; else goto <bb 6>; <bb 5>: goto <bb 4>; <bb 6>: # i_24 = PHI <i_12(4)> _2 = (sizetype) i_24; _3 = _2 * 4; _1 = &a + _3; a_p = _1; which may or may not be a good thing - this way IVOPTs can see the extra use of i_12 on the loop exit and it _could_ look for derived uses of that so it _may_ be able to replace the use of i_24 with something better.
