https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71237
Bug ID: 71237
Summary: scev tests failing after pass reorganization
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: andre.simoesdiasvieira at arm dot com
Target Milestone: ---
Ever since the reorganization of the passes moving lim before sink makes these
tests fail.
FAIL: gcc.dg/tree-ssa/scev-3.c scan-tree-dump-times optimized "&a" 1
FAIL: gcc.dg/tree-ssa/scev-4.c scan-tree-dump-times optimized "&a" 1
FAIL: gcc.dg/tree-ssa/scev-5.c scan-tree-dump-times optimized "&a" 1
This was first reported in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52563#c11
for sparc*-*-solaris2.*, it also fails on arm-none-eabi.
Some further discussions on that thread.
Quoting Richard:
[email protected] 2016-05-23 07:40:31 UTC
>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.
