From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2141 invoked by alias); 3 Aug 2015 17:20:37 -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 2130 invoked by uid 89); 3 Aug 2015 17:20:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: eu-smtp-delivery-143.mimecast.com Received: from eu-smtp-delivery-143.mimecast.com (HELO eu-smtp-delivery-143.mimecast.com) (207.82.80.143) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 03 Aug 2015 17:20:35 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-26-EHJy6CTYQD-uJAHjncogRA-1; Mon, 03 Aug 2015 18:20:30 +0100 Received: from [10.2.207.50] ([10.1.2.79]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2015 18:20:30 +0100 Message-ID: <55BFA2DB.1040507@arm.com> Date: Mon, 03 Aug 2015 17:20: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: Uros Bizjak CC: "gcc-patches@gcc.gnu.org" , Jeff Law , "H.J. Lu" Subject: Re: [PATCH][RTL-ifcvt] Improve conditional select ops on immediates References: <55BF666A.5000008@arm.com> <55BF6FE5.8020902@arm.com> <55BF8AAF.7060101@arm.com> <55BF8E7F.2010108@arm.com> In-Reply-To: <55BF8E7F.2010108@arm.com> X-MC-Unique: EHJy6CTYQD-uJAHjncogRA-1 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg00101.txt.bz2 On 03/08/15 16:53, Kyrill Tkachov wrote: > On 03/08/15 16:45, Uros Bizjak wrote: >> On Mon, Aug 3, 2015 at 5:37 PM, Kyrill Tkachov = wrote: >> >>>> Looking at the x86 movcc expansion code (ix86_expand_int_movcc) I >>>> don't think this is a good idea. In the expander, there is already >>>> quite some target-dependent code that goes great length to utilize sbb >>>> insn as much as possible, before cmove is used. >>>> >>>> IMO, as far as x86 is concerned, the best solution would be to revert >>>> the change. ix86_expand_int_movcc already does some tricks from your >>>> patch in a target-efficient way. Generic change that was introduced by >>>> your patch now interferes with this expansion. >>> Well, technically the transformation was already there, it was just nev= er >>> reached for an x86 compilation because noce_try_cmove was tried in fron= t of >>> it >>> and used a target-specific expansion. >>> In any case, how's this proposal? >>> The transformation noce_try_store_flag_constants >>> /* if (test) x =3D a; else x =3D b; >>> =3D> x =3D (-(test !=3D 0) & (b - a)) + a; */ >>> >>> Is a catch-all-immediates transformation in noce_try_store_flag_constan= ts. >>> What if we moved it to noce_try_cmove and performed it only if the >>> target-specific >>> conditional move expansion there failed? >>> >>> That way we can try the x86_64-specific sequence first and still give t= he >>> opportunity >>> to noce_try_store_flag_constants to perform the transformations that can >>> benefit targets >>> that don't have highly specific conditional move expanders. >> Yes, let's try this approach. As was found out, some targets (e.g. >> x86) hide lots of different target-dependent expansion strategies into >> movcc expander. Perhaps this fact should be documented in the comment >> in the generic code? > Ok, I'll work on that approach and add a comment. I'm testing a patch that fix the testcases on x86_64 and does not harm codegen on aarch64. Feel free to file a PR and assign it to me. Thanks, Kyrill > > Thanks, > Kyrill > > >> Uros. >>