This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: a patch for PR68695
- From: Kyrill Tkachov <kyrylo dot tkachov at foss dot arm dot com>
- To: Jakub Jelinek <jakub at redhat dot com>, Vladimir Makarov <vmakarov at redhat dot com>
- Cc: Christophe Lyon <christophe dot lyon at linaro dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 05 Apr 2016 10:48:58 +0100
- Subject: Re: a patch for PR68695
- Authentication-results: sourceware.org; auth=none
- References: <56FAAD47 dot 8090300 at redhat dot com> <CAKdteOahR87wrjssCmrTuUZD+776xUWN207xRj2VOmDER04xAA at mail dot gmail dot com> <56FED981 dot 1020609 at redhat dot com> <20160401204332 dot GH3017 at tucnak dot redhat dot com>
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