https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62028
Bug ID: 62028
Summary: Power64/Linux: FAIL: gcc.dg/sms-8.c
scan-rtl-dump-times sms "SMS succeeded" 0
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: ma...@linux-mips.org
CC: ma...@linux-mips.org, revital.eres at linaro dot org
Target: powerpc-linux-gnu
Created attachment 33252
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33252&action=edit
Test case source
I observe this failure:
FAIL: gcc.dg/sms-8.c scan-rtl-dump-times sms "SMS succeeded" 0
in 64-bit Power/Linux testing. The test case (source attached) has a
loop in `foo' that gets conditionally unrolled on 64-bit Power (but not
on 32-bit Power where this test case passes): the incoming value of
`ctr' is checked and if less than or equal to 2, then the unrolled loop
is branched to, otherwise execution falls through to the regular loop.
It is this unrolled loop that the SMS pass catches and handles I
believe which is probably correct.
What I am not sure of is whether this loop unrolling makes sense
performance-wise, especially considering the code size increase from
handling the two cases separately; someone with a better understanding
of Power pipelines would have to have a look into it.
Given the above I can't decide if it's the test case that is wrong and
should e.g. exclude 64-bit Power or if this is a genuine failure. The
test case binary executes successfully:
PASS: gcc.dg/sms-8.c execution test
so if a failure, then this is a missed optimisation rather than a code
correctness issue.
Options used to configure the compiler:
--build=i686-pc-linux-gnu
--target=powerpc-linux-gnu
--with-cpu-32=603e
--with-cpu-64=e5500
--with-long-double-128
Options used to build the test case:
-O2
-fdiagnostics-color=never
-fdump-rtl-sms
-ffat-lto-objects
-fmodulo-sched
-fmodulo-sched-allow-regmoves
-fno-diagnostics-show-caret
-m64
The same issue triggers if:
-mcpu=e6500
is additionally used with the test case.
