From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2834 invoked by alias); 23 Jul 2015 16:35:39 -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 2821 invoked by uid 89); 23 Jul 2015 16:35:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS 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, 23 Jul 2015 16:35:37 +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 t6NGXUT2030473; Thu, 23 Jul 2015 11:33:30 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id t6NGXTsX030472; Thu, 23 Jul 2015 11:33:29 -0500 Date: Thu, 23 Jul 2015 17:12:00 -0000 From: Segher Boessenkool To: Jeff Law Cc: Andrew Pinski , Richard Biener , Jakub Jelinek , "Hurugalawadi, Naveen" , "gcc-patches@gcc.gnu.org" Subject: Re: Fold some equal to and not equal to patterns in match.pd Message-ID: <20150723163329.GA27818@gate.crashing.org> References: <20150721093831.GF1780@tucnak.redhat.com> <0B875690-DCED-43AB-B964-67CDDCAF6776@gmail.com> <55B111CD.2030300@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55B111CD.2030300@redhat.com> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2015-07/txt/msg01957.txt.bz2 On Thu, Jul 23, 2015 at 10:09:49AM -0600, Jeff Law wrote: > It seems to me in these kind of cases that selection of the canonical > form should be driven by factors outside of which is better for a > particular target. ie, which is simpler I agree. But neither form is simpler here, and we need to have both forms in other contexts, so there is no real benefit to canonicalising. > Instead we should be looking at the gimple->rtl expansion phase to > expand using a form that is better for a particluar target. > > [And yes, I think I've violated this new guiding principle in the past] > > Given the (a << n) EQ/NE form, can we reasonably detect this in the > gimple->expansion phase and emit code as if we had the alternate form > for targets such as aarch64? In gimple, both forms have the same complexity as far as I see. In RTL both forms have the same complexity as well. RTX cost can be higher for the AND form (or, in theory at least, can be lower for some targets). In my opinion expand shouldn't do anything special here, just emit RTL like the gimple it is fed, and let the target deal with it, or the generic RTL optimisers. Or do we have an example where that does not work or is inconvenient? Segher