On Tue, Apr 05, 2016 at 10:48:58AM +0100, Kyrill Tkachov wrote: > 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.
The "new" code is better if there is no shrink-wrapping. We can probably teach prepare_shrink_wrap to do the extra register move if that will allow us to wrap more. > Though if so, it looks like a shrink-wrapping deficiency exposed by > this patch, rather than caused by it. Yes, and mostly a testcase problem even. > 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. RTL before shrink-wrapping would be useful, too. Segher