From patchwork Wed May 1 18:49:18 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Law X-Patchwork-Id: 1930338 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=ventanamicro.com header.i=@ventanamicro.com header.a=rsa-sha256 header.s=google header.b=Tkh2fYol; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=server2.sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=patchwork.ozlabs.org) Received: from server2.sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4VV5hr3hQFz1ymc for ; Thu, 2 May 2024 04:49:48 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B350A3858429 for ; Wed, 1 May 2024 18:49:46 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com [IPv6:2607:f8b0:4864:20::1136]) by sourceware.org (Postfix) with ESMTPS id E9D38385E83E for ; Wed, 1 May 2024 18:49:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E9D38385E83E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=ventanamicro.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ventanamicro.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E9D38385E83E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::1136 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714589364; cv=none; b=T79pVbWh1PSfHsGD2hCGnYn7herVdLtyLSvc/GN8Swg1jIIr7LaSYmh1MIInKxRINyIIflPpZwNW695woZWwvy2y0caoR81GdJBMEeWPDYPHhc1QV+bYf9iO1BzFag8jGNx5xVygy5J3/ooIAgbRZWyWmH9e6iPMGchrSV+yiNw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714589364; c=relaxed/simple; bh=zcQNG++gM70gCzUGVvz/fUdWa3qtb4aor3xcDgWEnU8=; h=DKIM-Signature:Message-ID:Date:MIME-Version:To:From:Subject; b=PU2Wduv029yNTA2ANTxqL4zMFehsj59zRj8elVHd1NpexzcZWvRKpM4APTFKjIggVPotixPxheke929MqQNMm/v9CKgIxpa/HSrOe5ddClkrk2ru0KcFm1GCxv4AQ942RZtHNpkLtwKlBpOtoQqkQX3kjTJPCaT8M89yS2wr7Pw= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-6181d032bf9so69216677b3.3 for ; Wed, 01 May 2024 11:49:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; t=1714589361; x=1715194161; darn=gcc.gnu.org; h=subject:from:to:content-language:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=KtKEUD2x8PXYWzQcCCf1jJPy87e5kGbM9RuOBvk0ias=; b=Tkh2fYol52fNm/9PedbErf63Br2FYA37EFVXKkCdu94KCe8xu08QBQbxV6dlIeyTHc I3+DJ7vRQwcthUgLTu5Tjk5b0rYwTjjDTRjweRMgFKU49Br3VmRMKNOJTB5QEW1rMkmm gy62RzXtGqIiRMqUU8gqzmN1X4pVwv6jACZbUHxHTDJ/ifb+Azu30pANut9TLBgpwS5L ao9c+AjVw7usYNWh/sgsYhUiyjSugbc6b31iSrMMSQEDOfK6DPJWkiEfhA0bKfxGjnNP fn8oebHCT6LK8r2uxcOsVnAODrFEVJGK/VaWdxDXse52XkrYAUmnJjBoZa46tbOwK91X HwjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714589361; x=1715194161; h=subject:from:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KtKEUD2x8PXYWzQcCCf1jJPy87e5kGbM9RuOBvk0ias=; b=E09DYYkDlzVCUZTMO1P3HOeyWm5x6YydohOQ00USTpgUZLHMYiLZBUv2VMZc0nrk2W S3kH15q2H9E0cTxzKJukrYbTjrFtO0wcKXFPWKqIHrjW8ztF2zU5bKp36iHfnVoe+oNQ SuKCBoI0sE5Uuhg5C/JBi44C/MCp0RtUPrQ9tvY2Yingw1umvZ1+MRw6A7befRtCQh+j cUkZkxTYA0+xB7DTth627DZaRsxUhl+Es5DQ+beqltODFRZq5rkoAEsUvjxoCFQD4wDy q2pI6jupO7/BN3VB0qrrs5JyEKRT/DOavXQyITUNtmWqsuam63fOWrgCTDbLfcjqq7iz 7oIg== X-Gm-Message-State: AOJu0YyOxJM8KHg+tDF7y+EBLlMV4O7lzj6oNvxULrve3Ve5nj2JBlxr yV3xM7Gbs7iWgadmp1384/W9TRMnol57oi6esKLQyDGt6XvE6jxOsLtZUDL0lj5B4YIkLIJF2mk 3 X-Google-Smtp-Source: AGHT+IEhZfCNTBds/XElve5625qySZ7WnMT1JCtP4D99JrcjY65o8jjjHnVjMiOMTZfepP5Tc1FvGA== X-Received: by 2002:a05:690c:4a02:b0:61b:1e81:4f65 with SMTP id ik2-20020a05690c4a0200b0061b1e814f65mr3921383ywb.0.1714589360728; Wed, 01 May 2024 11:49:20 -0700 (PDT) Received: from [172.31.0.109] ([136.36.72.243]) by smtp.gmail.com with ESMTPSA id d14-20020a0ddb0e000000b0061871ed807fsm6494384ywe.32.2024.05.01.11.49.19 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 May 2024 11:49:19 -0700 (PDT) Message-ID: Date: Wed, 1 May 2024 12:49:18 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Content-Language: en-US To: "gcc-patches@gcc.gnu.org" From: Jeff Law Subject: [committed] [RISC-V] Trivial pattern cleanup X-Spam-Status: No, score=-10.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP 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.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org As I was reviewing and cleaning up some internal work, I noticed a particular idiom being used elsewhere in the RISC-V backend. Specifically the use of explicit subregs when an adjustment to the match_operand would be sufficient. Let's take this example from the and-not splitter: > (define_split > [(set (match_operand:X 0 "register_operand") > (and:X (not:X (lshiftrt:X (match_operand:X 1 "register_operand") > (subreg:QI (match_operand:X 2 "register_operand") 0))) > (const_int 1)))] Note the explicit subreg. We can instead use a match_operand with QImode. This ever-so-slightly simplifies the machine description. It also means that if we have a QImode object lying around (say we loaded it from memory in QImode), we can use it directly rather than first extending it to X, then truncing to QI. So we end up with simpler RTL and in rare cases improve the code we generate. When used in a define_split or define_insn_and_split we need to make suitable adjustments to the split RTL. Bootstrapped a while back. Just re-tested with a cross. Pushing to the trunk & coordination branch. jeff commit 76ca6e1f8b1524b82a871ce29cf58c79e5e77e2b Author: Jeff Law Date: Wed May 1 12:43:37 2024 -0600 [committed] [RISC-V] Trivial pattern cleanup As I was reviewing and cleaning up some internal work, I noticed a particular idiom being used elsewhere in the RISC-V backend. Specifically the use of explicit subregs when an adjustment to the match_operand would be sufficient. Let's take this example from the and-not splitter: > (define_split > [(set (match_operand:X 0 "register_operand") > (and:X (not:X (lshiftrt:X (match_operand:X 1 "register_operand") > (subreg:QI (match_operand:X 2 "register_operand") 0))) > (const_int 1)))] Note the explicit subreg. We can instead use a match_operand with QImode. This ever-so-slightly simplifies the machine description. It also means that if we have a QImode object lying around (say we loaded it from memory in QImode), we can use it directly rather than first extending it to X, then truncing to QI. So we end up with simpler RTL and in rare cases improve the code we generate. When used in a define_split or define_insn_and_split we need to make suitable adjustments to the split RTL. Bootstrapped a while back. Just re-tested with a cross. gcc/ * config/riscv/bitmanip.md (splitter to use w-form division): Remove explicit subregs. (zero extended bitfield extraction): Similarly. * config/riscv/thead.md (*th_memidx_operand): Similarly. diff --git a/gcc/config/riscv/bitmanip.md b/gcc/config/riscv/bitmanip.md index ccda25c01c1..ad3ad758959 100644 --- a/gcc/config/riscv/bitmanip.md +++ b/gcc/config/riscv/bitmanip.md @@ -50,11 +50,11 @@ (define_split (sign_extend:DI (div:SI (plus:SI (ashift:SI (subreg:SI (match_operand:DI 1 "register_operand") 0) (match_operand:QI 2 "imm123_operand")) (subreg:SI (match_operand:DI 3 "register_operand") 0)) - (subreg:SI (match_operand:DI 4 "register_operand") 0)))) + (match_operand:SI 4 "register_operand")))) (clobber (match_operand:DI 5 "register_operand"))] "TARGET_64BIT && TARGET_ZBA" [(set (match_dup 5) (plus:DI (ashift:DI (match_dup 1) (match_dup 2)) (match_dup 3))) - (set (match_dup 0) (sign_extend:DI (div:SI (subreg:SI (match_dup 5) 0) (subreg:SI (match_dup 4) 0))))]) + (set (match_dup 0) (sign_extend:DI (div:SI (subreg:SI (match_dup 5) 0) (match_dup 4))))]) ; Zba does not provide W-forms of sh[123]add(.uw)?, which leads to an ; interesting irregularity: we can generate a signed 32-bit result @@ -722,13 +722,14 @@ (define_insn "*bexti" (define_split [(set (match_operand:X 0 "register_operand") (and:X (not:X (lshiftrt:X (match_operand:X 1 "register_operand") - (subreg:QI (match_operand:X 2 "register_operand") 0))) + (match_operand:QI 2 "register_operand"))) (const_int 1)))] "TARGET_ZBS" [(set (match_dup 0) (zero_extract:X (match_dup 1) (const_int 1) (match_dup 2))) - (set (match_dup 0) (xor:X (match_dup 0) (const_int 1)))]) + (set (match_dup 0) (xor:X (match_dup 0) (const_int 1)))] + "operands[2] = gen_lowpart (mode, operands[2]);") ;; We can create a polarity-reversed mask (i.e. bit N -> { set = 0, clear = -1 }) ;; using a bext(i) followed by an addi instruction. diff --git a/gcc/config/riscv/thead.md b/gcc/config/riscv/thead.md index 5c7d4beb1b6..a47fe6f28b8 100644 --- a/gcc/config/riscv/thead.md +++ b/gcc/config/riscv/thead.md @@ -466,12 +466,12 @@ (define_insn "*th_mempair_load_zero_extendsidi2" (define_insn_and_split "*th_memidx_operand" [(set (match_operand:DI 0 "register_operand" "=r") (ashift:DI - (zero_extend:DI (subreg:SI (match_operand:DI 1 "register_operand" "r") 0)) + (zero_extend:DI (match_operand:SI 1 "register_operand" "r")) (match_operand 2 "const_int_operand" "n")))] "TARGET_64BIT && TARGET_XTHEADMEMIDX && lra_in_progress" "#" "" - [(set (match_dup 0) (zero_extend:DI (subreg:SI (match_dup 1) 0))) + [(set (match_dup 0) (zero_extend:DI (match_dup 1))) (set (match_dup 0) (ashift:DI (match_dup 0) (match_dup 2)))] "" [(set_attr "type" "bitmanip")])