From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63542 invoked by alias); 12 May 2015 09:08:26 -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 63454 invoked by uid 89); 12 May 2015 09:08:25 -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; Tue, 12 May 2015 09:08:14 +0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by uk-mta-18.uk.mimecast.lan; Tue, 12 May 2015 10:08:11 +0100 Received: from [10.2.207.50] ([10.1.2.79]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 May 2015 10:08:04 +0100 Message-ID: <5551C2F4.7090504@arm.com> Date: Tue, 12 May 2015 09:09: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> <554219AC.80103@arm.com> In-Reply-To: <554219AC.80103@arm.com> X-MC-Unique: 9oKCOXsWTma7Elk_efbiHg-3 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg01056.txt.bz2 Ping^2. Thanks, Kyrill On 30/04/15 13:01, Kyrill Tkachov wrote: > 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 fun= ctions 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 genera= te 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 o= f QImode add operations >> (how would we? we don't have define_insns for such things) but the RTL o= ptimisers will get a hold >> of the UNSPEC_VOLATILE in the meantime and ask for it's cost (for exampl= e, 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_c= ost and handling it there >> (very straightforwardly just returning COSTS_N_INSNS (2); there's no ind= ication 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 obviou= sly useless rtxes in the backend. >> The astute reader might notice that in sync.md we also have the pattern = atomic_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 mi= ght have rtx costs called on it >> as well. This will always be a (plus (reg) (mem)) rtx, which is unlike a= ny 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 compi= led codebases. >> >> Ok for trunk? >> >> P.S. I know that expmed creates all kinds of irregular rtxes and asks fo= r 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.