Hi all,
On 01/04/16 21:43, Jakub Jelinek wrote:
On Fri, Apr 01, 2016 at 04:26:41PM -0400, Vladimir Makarov wrote:
I've noticed that after this patch, 2 tests regress (PASS -> FAIL) on arm:
gcc.dg/ira-shrinkwrap-prep-2.c scan-rtl-dump pro_and_epilogue
"Performing shrink-wrapping"
gcc.dg/pr10474.c scan-rtl-dump pro_and_epilogue "Performing shrink-wrapping"
I've checked the generated code. RA with the patch generates a better code
for the both tests. So shrink wrap optimization failed. The final code has 1
insn less for the both tests when the patch is applied.
I guess it is wrong to write quality tests based on expected code generated
before any optimization. It has sense if we provide the same input. LLVM
testsuite is mostly such tests as they have a readable IR. GCC
unfortunately has no serialized and readable IR. On the other hand LLVM
lacks integrated testing.
So I'd mark these tests as XFAIL or removed arm from DEJAGNU target in the
tests.
FYI, those 2 tests also now FAIL on ppc64{,le}-linux in addition to
armv7hl-linux-gnueabi.
So for the test gcc.dg/pr10474.c on arm with -marm -O3 before this patch we
perform shrink-wrapping:
cmp r0, #0
bxeq lr
push {r4, lr}
mov r4, r0
...
And after the patch we don't:
push {r4, lr}
subs r4, r0, #0
popeq {r4, pc}
...
The assembly after the "..." is identical.
So the resulting code is indeed shorter, though there is an
extra stack push and pop on the early return path.
A similar effect appears on gcc.dg/ira-shrinkwrap-prep-2.c.
I think both codegen decisions are valid though one
could argue that the new codegen is more appropriate for
-Os rather than -O3. If you agree then this is indeed a regression.
Though if so, it looks like a shrink-wrapping deficiency exposed by
this patch, rather than caused by it.
Jakub, do you happen to have the before and after codegen for these tests
on ppc64? I wonder if the effect is more clearcut there.
Thanks,
Kyrill
Jakub
