From patchwork Tue Dec 8 09:21:29 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kyrylo Tkachov X-Patchwork-Id: 57838 Delivered-To: patch@linaro.org Received: by 10.112.147.194 with SMTP id tm2csp1672920lbb; Tue, 8 Dec 2015 01:21:48 -0800 (PST) X-Received: by 10.98.67.201 with SMTP id l70mr3401104pfi.29.1449566508421; Tue, 08 Dec 2015 01:21:48 -0800 (PST) Return-Path: Received: from sourceware.org (server1.sourceware.org. [209.132.180.131]) by mx.google.com with ESMTPS id r22si4044009pfr.22.2015.12.08.01.21.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Dec 2015 01:21:48 -0800 (PST) Received-SPF: pass (google.com: domain of gcc-patches-return-416650-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) client-ip=209.132.180.131; Authentication-Results: mx.google.com; spf=pass (google.com: domain of gcc-patches-return-416650-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) smtp.mailfrom=gcc-patches-return-416650-patch=linaro.org@gcc.gnu.org; dkim=pass header.i=@gcc.gnu.org DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:content-type; q=dns; s=default; b=c8tA8D/R0I10coO/Cohntx+nb7+vtBXXr4CVK+jOM32 j6i8b3cPGKw3E3TxHhroN7X+JSUsrB7pWP2qvAjamomFH7lp2YmSxtSzxlKxeU3U 1FlSWhpBu1dpaYvNT5LMvnBbh9f9eaSQ4/T3nHk4jWVp+ITyOhfqyr2sxoP0F1gk = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:content-type; s=default; bh=GGntoGWY6Le9leT+L4L5o1UoTIw=; b=HqlIAp4LLTLO6G8im LI7bXy13in/SsGNIKkLnR3renZeoUSOcI1b1PWzj8FyWUEW8BRYE93+9UDKoR8pm SYXsHRu+e1ClrkL1OXuSBjMWL1JWnvnvarwO/uwck1P+2hJMBnWAF0uxCLrcpemc FTt2f2oKw9oFQ8bIIZc3xIJ4jw= Received: (qmail 58592 invoked by alias); 8 Dec 2015 09:21:37 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 58578 invoked by uid 89); 8 Dec 2015 09:21:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 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, 08 Dec 2015 09:21:34 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-22-2CVj-SEATnCipJpObwpNWA-1; Tue, 08 Dec 2015 09:21:29 +0000 Received: from [10.2.206.200] ([10.1.2.79]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2015 09:21:29 +0000 Message-ID: <5666A119.8010206@arm.com> Date: Tue, 08 Dec 2015 09:21:29 +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: Marcus Shawcroft , Richard Earnshaw , James Greenhalgh Subject: [PATCH][AArch64] PR target/68696 FAIL: gcc.target/aarch64/vbslq_u64_1.c scan-assembler-times bif\tv 1 X-MC-Unique: 2CVj-SEATnCipJpObwpNWA-1 X-IsSubscribed: yes Hi all, The test gcc.target/aarch64/vbslq_u64_1.c started failing recently due to some tree-level changes. This just exposed a deficiency in our xor-and-xor pattern for the vector bit-select pattern: aarch64_simd_bsl_internal. We now fail to match the rtx: (set (reg:V4SI 79) (xor:V4SI (and:V4SI (xor:V4SI (reg:V4SI 32 v0 [ a ]) (reg/v:V4SI 77 [ b ])) (reg:V4SI 34 v2 [ mask ])) (reg/v:V4SI 77 [ b ]))) whereas before combine attempted: (set (reg:V4SI 79) (xor:V4SI (and:V4SI (xor:V4SI (reg/v:V4SI 77 [ b ]) (reg:V4SI 32 v0 [ a ])) (reg:V4SI 34 v2 [ mask ])) (reg/v:V4SI 77 [ b ]))) Note that just the order of the operands of the inner XOR has changed. This could be solved by making the second operand of the outer XOR a 4th operand of the pattern, enforcing that it should be equal to operand 2 or 3 in the pattern condition and performing the appropriate swapping in the output template. However, the aarch64_simd_bsl_internal pattern is expanded to by other places in aarch64-simd.md and updating all the callsites to add a 4th operand is wasteful and makes them harder to understand. Therefore this patch adds a new define_insn with the match_dup of operand 2 in the outer XOR. I also had to update the alternatives/constraints in the pattern and the output template. Basically it involves swapping operands 2 and 3 around in the constraints and output templates. The test now combines to a single vector bfi instruction again. Bootstrapped and tested on aarch64. Ok for trunk? Thanks, Kyrill 2015-12-08 Kyrylo Tkachov PR target/68696 * config/aarch64/aarch64-simd.md (*aarch64_simd_bsl_alt): New pattern. (aarch64_simd_bsl_internal): Update comment to reflect the above. diff --git a/gcc/config/aarch64/aarch64-simd.md b/gcc/config/aarch64/aarch64-simd.md index 030a1013caa8a965bcd1615c9686d0be715be921..2856f017c16380623960e21d66149d18efe176f0 100644 --- a/gcc/config/aarch64/aarch64-simd.md +++ b/gcc/config/aarch64/aarch64-simd.md @@ -2153,6 +2153,10 @@ (define_insn "aarch64_reduc__internal" ;; bit op0, op2, mask ;; if (op0 = op2) (so 0-bits in mask choose bits from op1, else op0) ;; bif op0, op1, mask +;; +;; This pattern is expanded to by the aarch64_simd_bsl expander. +;; Some forms of straight-line code may generate the equivalent form +;; in *aarch64_simd_bsl_alt. (define_insn "aarch64_simd_bsl_internal" [(set (match_operand:VSDQ_I_DI 0 "register_operand" "=w,w,w") @@ -2172,6 +2176,29 @@ (define_insn "aarch64_simd_bsl_internal" [(set_attr "type" "neon_bsl")] ) +;; We need this form in addition to the above pattern to match the case +;; when combine tries merging three insns such that the second operand of +;; the outer XOR matches the second operand of the inner XOR rather than +;; the first. The two are equivalent but since recog doesn't try all +;; permutations of commutative operations, we have to have a separate pattern. + +(define_insn "*aarch64_simd_bsl_alt" + [(set (match_operand:VSDQ_I_DI 0 "register_operand" "=w,w,w") + (xor:VSDQ_I_DI + (and:VSDQ_I_DI + (xor:VSDQ_I_DI + (match_operand:VSDQ_I_DI 3 "register_operand" "w,w,0") + (match_operand:VSDQ_I_DI 2 "register_operand" "w,0,w")) + (match_operand:VSDQ_I_DI 1 "register_operand" "0,w,w")) + (match_dup:VSDQ_I_DI 2)))] + "TARGET_SIMD" + "@ + bsl\\t%0., %3., %2. + bit\\t%0., %3., %1. + bif\\t%0., %2., %1." + [(set_attr "type" "neon_bsl")] +) + (define_expand "aarch64_simd_bsl" [(match_operand:VALLDIF 0 "register_operand") (match_operand: 1 "register_operand")