From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60910 invoked by alias); 3 Sep 2015 19:20:11 -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 60893 invoked by uid 89); 3 Sep 2015 19:20:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Thu, 03 Sep 2015 19:20:10 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.13.8) with ESMTP id t83JK3bd032143; Thu, 3 Sep 2015 14:20:03 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id t83JK2ZF032142; Thu, 3 Sep 2015 14:20:02 -0500 Date: Thu, 03 Sep 2015 19:22:00 -0000 From: Segher Boessenkool To: Wilco Dijkstra Cc: Jeff Law , "'GCC Patches'" Subject: Re: RFC: Combine of compare & and oddity Message-ID: <20150903192002.GE13559@gate.crashing.org> References: <000e01d0e5a2$1e2f66b0$5a8e3410$@com> <20150902184747.GA7676@gate.crashing.org> <000f01d0e63d$c40686e0$4c1394a0$@com> <20150903131809.GA27819@gate.crashing.org> <001001d0e659$1120bb60$33623220$@com> <55E870C0.7080606@redhat.com> <20150903163634.GB13559@gate.crashing.org> <001301d0e679$c8a210c0$59e63240$@com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001301d0e679$c8a210c0$59e63240$@com> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg00309.txt.bz2 On Thu, Sep 03, 2015 at 07:53:12PM +0100, Wilco Dijkstra wrote: > > > >>You will end up with a *lot* of target hooks like this. It will also > > > >>make testing harder (less coverage). I am not sure that is a good idea. > > > > > > > >We certainly need a lot more target hooks in general so GCC can do the > > > >right thing > > > >(rather than using costs inconsistently all over the place). But that's a > > > >different > > > >discussion... > > > Let's be very careful here, target hooks aren't always the solution. > > > I'd rather see the costing models fixed and use those across the board. > > > But frankly, I don't know how to fix the costing models. > > > > Combine doesn't currently use costs to decide how to simplify and > > canonicalise things. Simplifications are what is simpler RTL; combine's > > job is to make fewer RTL instructions (which is not the same thing as > > fewer machine instructions, or cheaper instructions). Changing what is > > canonical based on target hooks would be, uh, interesting. > > Would it be reasonable to query the rtx_cost of a compare+and and if the cost > is the same as an AND assume that that instruction does not need to be "improved" > into the canonical form? That way it will use the compare+and pattern if it exists > and still try the zero_extract/shift+and forms for targets that don't have a > compare+and instruction. At the point the canonicalisation is done you do not yet know if this is a valid instruction at all. Introducing more cost computations for random things is not such a great idea, and for RTL that can never be part of a machine instruction doubly so. I think we really should just change what is the canonical form for such a comparison. Segher