From patchwork Mon Jul 3 09:07:31 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Sandiford X-Patchwork-Id: 1802559 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=8.43.85.97; helo=server2.sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: legolas.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.a=rsa-sha256 header.s=default header.b=SOYfofbH; dkim-atps=neutral Received: from server2.sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4Qvg7J561tz20b1 for ; Mon, 3 Jul 2023 19:07:56 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 241363857C55 for ; Mon, 3 Jul 2023 09:07:54 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 241363857C55 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1688375274; bh=mzgs0K0Xz+v3EeWOCpJ+JRuJkVTwSbnnz183stkfhjg=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=SOYfofbHK1XZUeMlLPIEnZaeMT0bvxc3fsboNzcp9t8it+0x6ia42Imv/F4wgKiY0 49mVWyGGWWR2hfOKfgVDOz4TDh4SaWCVzc49ZjUAyoDCN+Jn7L7k1DdOZoU0pbAZr5 D2l6/vKECGUYAsbn/OZdlXXxo1MAuGINbOZoeFiE= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 4E7F53858D28 for ; Mon, 3 Jul 2023 09:07:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4E7F53858D28 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7B3E61FB for ; Mon, 3 Jul 2023 02:08:15 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7D9E83F762 for ; Mon, 3 Jul 2023 02:07:32 -0700 (PDT) To: gcc-patches@gcc.gnu.org Mail-Followup-To: gcc-patches@gcc.gnu.org, richard.sandiford@arm.com Subject: [PATCH] aarch64: Fix vector-to-vector vec_extract Date: Mon, 03 Jul 2023 10:07:31 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Spam-Status: No, score=-26.7 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_ASCII_DIVIDERS, KAM_DMARC_NONE, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Richard Sandiford via Gcc-patches From: Richard Sandiford Reply-To: Richard Sandiford Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org Sender: "Gcc-patches" The documentation says: ------------------------------------------------------------------------- @cindex @code{vec_extract@var{m}@var{n}} instruction pattern @item @samp{vec_extract@var{m}@var{n}} Extract given field from the vector value. [...] The @var{n} mode is the mode of the field or vector of fields that should be extracted, [...] If @var{n} is a vector mode, the index is counted in units of that mode. ------------------------------------------------------------------------- However, Robin pointed out that, in practice, the index is counted in whole multiples of @var{n}. These are the semantics that x86 and target-independent code follow. This patch updates the aarch64 pattern to match, which also removes the FAIL. I think Robin has patches that update the documentation and make more use of the de facto semantics. I haven't found an existing testcase that shows the difference. We do now use the pattern for: union u { int32x4_t x; int32x2_t y[2]; }; int32x2_t f(int32x4_t x) { union u u = { x }; return u.y[1]; } but we were already generating perfect code for it. Because of that, it didn't really seem worth adding a specific dump test. Tested on aarch64-linux-gnu & pushed. Richard gcc/ * config/aarch64/aarch64-simd.md (vec_extract): Expect the index to be 0 or 1. --- gcc/config/aarch64/aarch64-simd.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gcc/config/aarch64/aarch64-simd.md b/gcc/config/aarch64/aarch64-simd.md index f1687d92eb2..d9539410147 100644 --- a/gcc/config/aarch64/aarch64-simd.md +++ b/gcc/config/aarch64/aarch64-simd.md @@ -8755,8 +8755,8 @@ (define_expand "vec_extract" "TARGET_SIMD" { int start = INTVAL (operands[2]); - if (start != 0 && start != / 2) - FAIL; + gcc_assert (start == 0 || start == 1); + start *= / 2; rtx sel = aarch64_gen_stepped_int_parallel ( / 2, start, 1); emit_insn (gen_aarch64_get_half (operands[0], operands[1], sel)); DONE;