From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49728 invoked by alias); 3 Sep 2015 18:42:57 -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 49711 invoked by uid 89); 3 Sep 2015 18:42:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 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; Thu, 03 Sep 2015 18:42:53 +0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-14-Hg7SYFHgTsis8Lulhpt6aA-1; Thu, 03 Sep 2015 19:42:48 +0100 Received: from e103246vm ([10.1.2.79]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2015 19:42:47 +0100 From: "Wilco Dijkstra" To: "'Oleg Endo'" , "Segher Boessenkool" Cc: "Kyrylo Tkachov" , "GCC Patches" References: <000e01d0e5a2$1e2f66b0$5a8e3410$@com> <20150902184747.GA7676@gate.crashing.org> <000f01d0e63d$c40686e0$4c1394a0$@com> <20150903131809.GA27819@gate.crashing.org> <001001d0e659$1120bb60$33623220$@com> <20150903161825.GA13559@gate.crashing.org> <55E87487.4060101@arm.com> <20150903165419.GC13559@gate.crashing.org> <7A96A790-FDEA-4967-8656-4A76ECDD8E07@t-online.de> In-Reply-To: <7A96A790-FDEA-4967-8656-4A76ECDD8E07@t-online.de> Subject: RE: RFC: Combine of compare & and oddity Date: Thu, 03 Sep 2015 18:53:00 -0000 Message-ID: <001201d0e678$51a05370$f4e0fa50$@com> MIME-Version: 1.0 X-MC-Unique: Hg7SYFHgTsis8Lulhpt6aA-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2015-09/txt/msg00303.txt.bz2 > Oleg Endo wrote: > On 04 Sep 2015, at 01:54, Segher Boessenkool = wrote: >=20 > > On Thu, Sep 03, 2015 at 05:25:43PM +0100, Kyrill Tkachov wrote: > >>> void g(void); > >>> void f(int *x) { if (*x & 2) g(); } > > > >> A testcase I was looking at is: > >> int > >> foo (int a) > >> { > >> return (a & 7) !=3D 0; > >> } > >> > >> For me this generates: > >> and w0, w0, 7 > >> cmp w0, wzr > >> cset w0, ne > >> ret > >> > >> when it could be: > >> tst w0, 7 > >> cset w0, ne > >> ret > > > > Interesting, thanks. > > > > That testcase with 4 (instead of 7) results in a single ubfx (a zero_ex= tract) > > (this case is written differently before combine already, however). > > With 6 it does what you want (combine does not handle it as an extract, > > no matter what the docs say); and 7 is as you say (combine tries the ex= tract, > > there is no insn like that). (a & 1) !=3D 0 is optimized earlier to a & 1, (a & 2) !=3D 0 to a real zero= _extract=20 (non-zero shift), so these cases don't need a compare. return (a & C) ? 2 := 3=20 always uses a compare with zero, even for C=3D1. > I've been through this on SH. As it currently stands, to generate tst in= sns basically 4 > different combine patterns are required: > - lsb (e.g. & 1) > - one bit (zero extract, e.g. & 2) > - n contiguous bits (zero extract, e.g. & 7) > - everything else (e.g. 4) Also: (a & 255) and (a & 65535) which are converted into zero_extend by com= bine. Interestingly a subreg is used depending on whether the operand is a virtua= l or physical reg - ((a + 1) & 255) =3D=3D 0 vs (a & 65535) =3D=3D 0: Failed to match this instruction: (set (reg:CC_ZESWP 66 cc) (compare:CC_ZESWP (reg:HI 0 x0 [ xD.2661 ]) (const_int 0 [0]))) Failed to match this instruction: (set (reg:CC_ZESWP 66 cc) (compare:CC_ZESWP (subreg:QI (reg:SI 80 [ D.2778 ]) 0) (const_int 0 [0]))) So that means another 2 patterns - and all that for one simple instruction.= .. Wilco