From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 74753 invoked by alias); 21 May 2015 16:59:15 -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 74738 invoked by uid 89); 21 May 2015 16:59:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 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; Thu, 21 May 2015 16:59:11 +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 F157328; Thu, 21 May 2015 09:59:04 -0700 (PDT) Received: from [10.2.207.50] (e100706-lin.cambridge.arm.com [10.2.207.50]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 692E43F4FF; Thu, 21 May 2015 09:59:08 -0700 (PDT) Message-ID: <555E0EDA.60103@foss.arm.com> Date: Thu, 21 May 2015 17:00: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> <5551C2F4.7090504@arm.com> In-Reply-To: <5551C2F4.7090504@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-05/txt/msg02006.txt.bz2 Ping^3. Thanks, Kyrill On 12/05/15 10:08, Kyrill Tkachov wrote: > 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 functions 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 generate 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 optimisers 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_cost and handling it there >>> (very straightforwardly just returning COSTS_N_INSNS (2); there's no indication 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 obviously 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" "=&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 might have rtx costs called on it >>> as well. This will always be a (plus (reg) (mem)) rtx, which is unlike any 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 compiled 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.