From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) by sourceware.org (Postfix) with ESMTPS id 69F523858D35 for ; Thu, 29 Jun 2023 07:39:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 69F523858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=vrull.eu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=vrull.eu Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-313e34ab99fso386318f8f.1 for ; Thu, 29 Jun 2023 00:39:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrull.eu; s=google; t=1688024380; x=1690616380; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=JXjv3b7XoA0OqeC5t7q1aJmji+plDUJDlKb7geqCTp0=; b=GATA6uNhykEjNgoIs3NDXPsxKvNQIH5VhvDKzc5hZfhzj09OGi4PrbSkb+VroyXQkm QZDc86pLdAkwSyGEVGUsqIpbzlyWqlflfcSrUul3AonzV7NxFZ2fgC731ukhlUU60l2N 4dU13s36vLp+m1QKTlP0BnCLYWFxoBVIxPLmP4W1t4ncNT0olDjijIyXWjTYdzE0MAmo xEdejsQOGYmJbPSDswrJjCHAO0yIx2bDoBZ3gVkGXvU+CGmUnxtYAxbTqFZK0WEzLW5C +YrJBgVQ+lVFq2BxrwEP9q2BLT/APYyHVhvoONtcYjCVSzkRxZN/GILQ2wz0k7KXjY5y x6SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688024380; x=1690616380; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JXjv3b7XoA0OqeC5t7q1aJmji+plDUJDlKb7geqCTp0=; b=LBvwdkHm2OUlJ0pT+xasCSK3QkiXgTVDu/uHGv0f6a08vni1CkNqlswrPEp+6p29F8 ZWVgWwb8135w2cBcyU7YrouB2ksqDBz/+wK/TTC+22AZPUreDyItnyfcJx5FgRoFQ0bn DGNH+4gEEP8dQtC8HHf8/BJdlKek8kNh0nre/N3BJAKXaHNoXdJIKIwtXbombkse/n89 XiIRF4l3O98HK/iFYUJrOb2Yi2Cpkxn6lyAkxKZTaGdLIg7fgWe4yi+1BjUqCndgbnoP ZZEVLQlsasCiOVW+G1GZuFCga6dLEgFip5uuM9objza8OJUrXsikd/aCSUcnITgWmJXw PD6Q== X-Gm-Message-State: AC+VfDwK6e6Z1yDCLWC6559E74JMYjP2isIHhwHH470prVyRhEKxgN55 L2dByMUAbpTj7KB9TZJzdLQj2Jzlmp+EgLjJUlTY1A== X-Google-Smtp-Source: ACHHUZ7EryULX6xwBf8DKre02xb0jyEJ8Al48Ul+EDOllKZ3WQGXl2P6wGz2WBPfh/eOSr8rfZATkBQjxJJF7JE3+cI= X-Received: by 2002:adf:e549:0:b0:313:e9f6:3378 with SMTP id z9-20020adfe549000000b00313e9f63378mr10868644wrm.4.1688024379981; Thu, 29 Jun 2023 00:39:39 -0700 (PDT) MIME-Version: 1.0 References: <20230428062314.2995571-1-christoph.muellner@vrull.eu> <0e13e932-64c4-fe33-e0f8-21380809a6ba@gmail.com> In-Reply-To: <0e13e932-64c4-fe33-e0f8-21380809a6ba@gmail.com> From: =?UTF-8?Q?Christoph_M=C3=BCllner?= Date: Thu, 29 Jun 2023 09:39:28 +0200 Message-ID: Subject: Re: [PATCH 10/11] riscv: thead: Add support for the XTheadMemIdx ISA extension To: Jeff Law Cc: gcc-patches@gcc.gnu.org, Kito Cheng , Jim Wilson , Palmer Dabbelt , Andrew Waterman , Philipp Tomsich , Cooper Qu , Lifang Xia , Yunhai Shang , Zhiwei Liu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no 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 Wed, Jun 28, 2023 at 8:23=E2=80=AFPM Jeff Law wr= ote: > > > > On 6/28/23 06:39, Christoph M=C3=BCllner 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))) > >>> +;; =3D=3D> > >>> +;; (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. Ok, understood. It is a bit of a special case here, because the peephole is restricted to those cases, where reg0 is not used elsewhere (peep2_reg_dead_p()). I have not seen how to do this for combiner optimizations. I found sh_remove_reg_dead_or_unused_notes(), which tests for reg notes on a given rtx_insn. In our case we have a pattern that matches two insns, where we have to test if one operand (reg0) is dead or unused after the sec= ond insn. The first insn can be accessed with "curr_insn", but I did not see ho= w to access the second matching insn. Any ideas or hints? Thanks, Christoph > > > > > > 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