From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43858 invoked by alias); 15 Apr 2016 11:06:32 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 43837 invoked by uid 89); 15 Apr 2016 11:06:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=marm, teach X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 15 Apr 2016 11:06:30 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 06ECA3C; Fri, 15 Apr 2016 04:05:14 -0700 (PDT) Received: from [10.2.206.200] (e100706-lin.cambridge.arm.com [10.2.206.200]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8E59F3F25F; Fri, 15 Apr 2016 04:06:27 -0700 (PDT) Message-ID: <5710CB31.9050801@foss.arm.com> Date: Fri, 15 Apr 2016 11:06:00 -0000 From: Kyrill Tkachov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Segher Boessenkool CC: Jakub Jelinek , Vladimir Makarov , Christophe Lyon , gcc-patches Subject: Re: a patch for PR68695 References: <56FAAD47.8090300@redhat.com> <56FED981.1020609@redhat.com> <20160401204332.GH3017@tucnak.redhat.com> <57038A0A.4030008@foss.arm.com> <20160405223510.GA18969@gate.crashing.org> In-Reply-To: <20160405223510.GA18969@gate.crashing.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-04/txt/msg00713.txt.bz2 On 05/04/16 23:35, Segher Boessenkool wrote: > 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. So what shall we do for these tests for GCC 6? Add an XFAIL for arm and powerpc? Kyrill > > Segher