From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19011 invoked by alias); 20 Apr 2015 16:28:58 -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 18999 invoked by uid 89); 20 Apr 2015 16:28:57 -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) (146.101.78.143) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 20 Apr 2015 16:28:56 +0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by uk-mta-23.uk.mimecast.lan; Mon, 20 Apr 2015 17:28:53 +0100 Received: from [10.2.207.50] ([10.1.2.79]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Apr 2015 17:28:52 +0100 Message-ID: <55352944.8070109@arm.com> Date: Mon, 20 Apr 2015 16:28: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: [PATCH][ARM] Handle UNSPEC_VOLATILE in rtx costs and don't recurse inside the unspec X-MC-Unique: Xn98i7hOT3Wi7KziqxWuYw-1 Content-Type: multipart/mixed; boundary="------------020101060302040900020309" X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg01047.txt.bz2 This is a multi-part message in MIME format. --------------020101060302040900020309 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-length: 2930 Hi all, A pet project of mine is to get to the point where backend rtx costs functi= ons 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 Q= Imode add operations (how would we? we don't have define_insns for such things) but the RTL opti= misers 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 rt= x 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 indica= tion 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 ato= mic_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 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 st= ill 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 t= heir 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. --------------020101060302040900020309 Content-Type: text/x-patch; name=arm-costs-unspecv.patch Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="arm-costs-unspecv.patch" Content-length: 1286 commit b86d4036fbbbd15956595ef5a158e1a6881356c1 Author: Kyrylo Tkachov Date: Thu Apr 16 11:17:47 2015 +0100 [ARM] Handle UNSPEC_VOLATILE in costs and don't recurse inside the unsp= ec diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c index 5116817..8f31be0 100644 --- a/gcc/config/arm/arm.c +++ b/gcc/config/arm/arm.c @@ -9607,7 +9607,8 @@ static bool arm_unspec_cost (rtx x, enum rtx_code /* outer_code */, bool speed_p, int = *cost) { const struct cpu_cost_table *extra_cost =3D current_tune->insn_extra_cos= t; - gcc_assert (GET_CODE (x) =3D=3D UNSPEC); + rtx_code code =3D GET_CODE (x); + gcc_assert (code =3D=3D UNSPEC || code =3D=3D UNSPEC_VOLATILE); =20 switch (XINT (x, 1)) { @@ -9653,7 +9654,7 @@ arm_unspec_cost (rtx x, enum rtx_code /* outer_code *= /, bool speed_p, int *cost) *cost =3D COSTS_N_INSNS (2); break; } - return false; + return true; } =20 /* Cost of a libcall. We assume one insn per argument, an amount for the @@ -11121,6 +11122,7 @@ arm_new_rtx_costs (rtx x, enum rtx_code code, enum = rtx_code outer_code, *cost =3D LIBCALL_COST (1); return false; =20 + case UNSPEC_VOLATILE: case UNSPEC: return arm_unspec_cost (x, outer_code, speed_p, cost); =20 --------------020101060302040900020309--