From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17805 invoked by alias); 11 Sep 2015 09:04:18 -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 17788 invoked by uid 89); 11 Sep 2015 09:04:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients 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, 11 Sep 2015 09:04:17 +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 C88F975; Fri, 11 Sep 2015 02:04:27 -0700 (PDT) Received: from e105545-lin (e105545-lin.cambridge.arm.com [10.2.206.27]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 215993F317; Fri, 11 Sep 2015 02:04:14 -0700 (PDT) Date: Fri, 11 Sep 2015 09:08:00 -0000 From: Ramana Radhakrishnan To: Bernd Schmidt Cc: Jeff Law , James Greenhalgh , gcc-patches@gcc.gnu.org, ebotcazou@libertysurf.fr, steven@gcc.gnu.org Subject: Re: [Patch] Teach RTL ifcvt to handle multiple simple set instructions Message-ID: <20150911090412.GB31587@e105545-lin> References: <1441724029-3124-1-git-send-email-james.greenhalgh@arm.com> <55F1CAA0.1000401@t-online.de> <55F1F1ED.9060008@redhat.com> <55F29679.6030703@t-online.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55F29679.6030703@t-online.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg00772.txt.bz2 On Fri, Sep 11, 2015 at 10:53:13AM +0200, Bernd Schmidt wrote: > On 09/10/2015 11:11 PM, Jeff Law wrote: > >I think that's probably what James is most interested in getting some > >ideas around -- the cost model. > > > >I think the fundamental problem is BRANCH_COST isn't actually relative > >to anything other than the default value of "1". It doesn't directly > >correspond to COSTS_N_INSNS or anything else. So while using > >COSTS_N_INSNS (BRANCH_COST)) would seem to make sense, it actually > >doesn't. It's not even clear how a value of 10 relates to a value of 1 > >other than it's more expensive. > > > >ifcvt (and others) comparing to magic #s is more than a bit lame. But > >with BRANCH_COST having no meaning relative to anything else I can see > >why Richard did things that way. > > > >In an ideal world we'd find some mapping from BRANCH_COST that relates > >to CONST_N_INSNS. I suspect a simple mapping doesn't necessarily exist > >and we'll likely regress targets with any simplistic mapping. But maybe > >now is the time to address that fundamental problem and deal with the > >fallout. > > I think the right approach if we want to fix this is a new > branch_cost_ninsns target hook (maybe with arguments > taken_percentage, predictability), and gradually move everything to > use that instead of BRANCH_COST. Perhaps providing backends with the entire if-then-else block along with the above mentioned information being if converted may be another approach, it allows the backends to analyse what cases are good to if-convert as per the ISA or micro-architecture and what aren't. regards Ramana