From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 70171 invoked by alias); 30 Apr 2015 12:01:56 -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 70147 invoked by uid 89); 30 Apr 2015 12:01:55 -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, 30 Apr 2015 12:01:52 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by uk-mta-12.uk.mimecast.lan; Thu, 30 Apr 2015 13:01:49 +0100 Received: from [10.2.207.50] ([10.1.2.79]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Apr 2015 13:01:49 +0100 Message-ID: <554219AC.80103@arm.com> Date: Thu, 30 Apr 2015 12:07: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: GCC Patches CC: Ramana Radhakrishnan , Richard Earnshaw Subject: Re: [PATCH][ARM] Handle UNSPEC_VOLATILE in rtx costs and don't recurse inside the unspec References: <55352944.8070109@arm.com> In-Reply-To: <55352944.8070109@arm.com> X-MC-Unique: lsuZdDnfQiSwH4CSJbl-qw-1 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg02015.txt.bz2 Ping. https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01047.html Thanks, Kyrill On 20/04/15 17:28, Kyrill Tkachov wrote: > Hi all, > > A pet project of mine is to get to the point where backend rtx costs func= tions won't have > to handle rtxes that don't match down to any patterns/expanders we have. = Or at least limit such cases. > A case dealt with in this patch is QImode PLUS. We don't actually generat= e or handle these anywhere in > the arm backend *except* in sync.md where, for example, atomic_ matches: > (set (match_operand:QHSD 0 "mem_noofs_operand" "+Ua") > (unspec_volatile:QHSD > [(syncop:QHSD (match_dup 0) > (match_operand:QHSD 1 "" "")) > (match_operand:SI 2 "const_int_operand")] ;; model > VUNSPEC_ATOMIC_OP)) > > Here QHSD can contain QImode and HImode while syncop can be PLUS. > Now immediately during splitting in arm_split_atomic_op we convert that > QImode PLUS into an SImode one, so we never actually generate any kind of= QImode add operations > (how would we? we don't have define_insns for such things) but the RTL op= timisers will get a hold > of the UNSPEC_VOLATILE in the meantime and ask for it's cost (for example= , cse when building libatomic). > Currently we don't handle UNSPEC_VOLATILE (VUNSPEC_ATOMIC_OP) so the arm = rtx costs function just recurses > into the QImode PLUS that I'd like to avoid. > This patch stops that by passing the VUNSPEC_ATOMIC_OP into arm_unspec_co= st and handling it there > (very straightforwardly just returning COSTS_N_INSNS (2); there's no indi= cation that we want to do anything > smarter here) and stopping the recursion. > > This is a small step in the direction of not having to care about obvious= ly useless rtxes in the backend. > The astute reader might notice that in sync.md we also have the pattern a= tomic_fetch_ > which expands to/matches this: > (set (match_operand:QHSD 0 "s_register_operand" "=3D&r") > (match_operand:QHSD 1 "mem_noofs_operand" "+Ua")) > (set (match_dup 1) > (unspec_volatile:QHSD > [(syncop:QHSD (match_dup 1) > (match_operand:QHSD 2 "" "")) > (match_operand:SI 3 "const_int_operand")] ;; model > VUNSPEC_ATOMIC_OP)) > > > Here the QImode PLUS is in a PARALLEL together with the UNSPEC, so it mig= ht have rtx costs called on it > as well. This will always be a (plus (reg) (mem)) rtx, which is unlike an= y other normal rtx we generate > in the arm backend. I'll try to get a patch to handle that case, but I'm = still thinking on how to best > do that. > > Tested arm-none-eabi, I didn't see any codegen differences in some compil= ed codebases. > > Ok for trunk? > > P.S. I know that expmed creates all kinds of irregular rtxes and asks for= their costs. I'm hoping to clean that > up at some point... > > 2015-04-20 Kyrylo Tkachov > > * config/arm/arm.c (arm_new_rtx_costs): Handle UNSPEC_VOLATILE. > (arm_unspec_cost): Allos UNSPEC_VOLATILE. Do not recurse inside > unknown unspecs.