From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) by sourceware.org (Postfix) with ESMTPS id B47833858D35 for ; Wed, 28 Jun 2023 18:23:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B47833858D35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pf1-x429.google.com with SMTP id d2e1a72fcca58-666eba6f3d6so9414b3a.3 for ; Wed, 28 Jun 2023 11:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687976601; x=1690568601; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=7G50boS1ILYb78o5ikCs2mBaG8d6Fq3ONv3ssCDp+Zw=; b=abB3RNW6Q3QE1W11UgSPaWYEylsm8kl/8epg/pP+36WIk1hBk8xJlw0woXMjWLgfLf bMIrpHYyOHmX6CnCwvaaS2zO63F3Q0ewCf5eHSQC/MmTrlKBudzhc/IiBN8vAhIj8TOL XDlYrlfp05GWdCW8oAwDnPTmoyLtttizHqmEkInTip3ZfqiZH/i4cDMzm0lOicObMKJX ohXsGySlpKdjc5Q/n8NIRlOzQNq+Re9IR1d+I59+2VSd4zFHeKUVes8ieqZ776rkTAO+ VtjA1uHdbAjr/HzsSUuSldJtV50j+1SEntPxflN7pSWvD/Gfe0L+mXAzpsufoqyvwksh g1Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687976601; x=1690568601; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7G50boS1ILYb78o5ikCs2mBaG8d6Fq3ONv3ssCDp+Zw=; b=eO4wMxypTmtejkaFfvyJrRb0llWR9GeNUWkermcUb8yA75DzyUSI+u3DOF6jz32IVy uIboweIAkUefYzsQnZ1TuB6iN4kvpxUx85crYbiRvISC5UpIXHhvZmObiOCFO6/LXFBd 1HKeoEM31nHPLGgsw8FmreKhDC4t8VeJnPVJlc5luvIffujlSG0qc7lc5DXnbGjPfxRh AoSDyt4QUh6e7ViX4KEgPslfmZ0C6ut+YPJDhZiOEkVUDgUYtwmO99zBs0or25Ofrn03 xlal3J7MCH5y5u5MqXNzfdC66sYxncSptdTBH2ngofDDRihrf15RjKxll/vD6O1+5YtW K/jg== X-Gm-Message-State: AC+VfDym3goxpZqPglFOOm4KvPfXGJNsO0AsFCv5ZOvUpenqIiIpYrtc mCIaWoDNfS62MVDcAGA9Fxw= X-Google-Smtp-Source: ACHHUZ7Lm1UTOkn2KP8BnNeUW2qMjVIBMUG0jebDOoWS6Ck5ED3jbQc0NqUSUtKZ8aO+ZpXNe/DDTQ== X-Received: by 2002:a05:6a21:3298:b0:127:7ea7:e039 with SMTP id yt24-20020a056a21329800b001277ea7e039mr8100472pzb.62.1687976600586; Wed, 28 Jun 2023 11:23:20 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id s12-20020a62e70c000000b00679a4b56e41sm4697025pfh.43.2023.06.28.11.23.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jun 2023 11:23:19 -0700 (PDT) Message-ID: <0e13e932-64c4-fe33-e0f8-21380809a6ba@gmail.com> Date: Wed, 28 Jun 2023 12:23:18 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH 10/11] riscv: thead: Add support for the XTheadMemIdx ISA extension Content-Language: en-US To: =?UTF-8?Q?Christoph_M=c3=bcllner?= Cc: gcc-patches@gcc.gnu.org, Kito Cheng , Jim Wilson , Palmer Dabbelt , Andrew Waterman , Philipp Tomsich , Cooper Qu , Lifang Xia , Yunhai Shang , Zhiwei Liu References: <20230428062314.2995571-1-christoph.muellner@vrull.eu> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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 List-Id: On 6/28/23 06:39, Christoph Müllner wrote: >>> +;; XTheadMemIdx overview: >>> +;; All peephole passes attempt to improve the operand utilization of >>> +;; XTheadMemIdx instructions, where one sign or zero extended >>> +;; register-index-operand can be shifted left by a 2-bit immediate. >>> +;; >>> +;; The basic idea is the following optimization: >>> +;; (set (reg 0) (op (reg 1) (imm 2))) >>> +;; (set (reg 3) (mem (plus (reg 0) (reg 4))) >>> +;; ==> >>> +;; (set (reg 3) (mem (plus (reg 4) (op2 (reg 1) (imm 2)))) >>> +;; This optimization only valid if (reg 0) has no further uses. >> Couldn't this be done by combine if you created define_insn patterns >> rather than define_peephole2 patterns? Similarly for the other cases >> handled here. > > I was inspired by XTheadMemPair, which merges two memory accesses > into a mem-pair instruction (and which got inspiration from > gcc/config/aarch64/aarch64-ldpstp.md). Right. I'm pretty familiar with those. They cover a different case, specifically the two insns being optimized don't have a true data dependency between them. ie, the first instruction does not produce a result used in the second insn. In the case above there is a data dependency on reg0. ie, the first instruction generates a result used in the second instruction. combine is usually the best place to handle the data dependency case. > > I don't see the benefit of using combine or peephole, but I can change > if necessary. At least for the provided test cases, the implementation > works quite well. Peepholes require the instructions to be consecutive in the stream while combine relies on data dependence links and can thus find these opportunities even when the two insn we care about are separated by unrelated other insns. Jeff