From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) by sourceware.org (Postfix) with ESMTPS id D161C385841E for ; Wed, 3 May 2023 10:23:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D161C385841E 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-lf1-x12b.google.com with SMTP id 2adb3069b0e04-4f00d41df22so2927999e87.1 for ; Wed, 03 May 2023 03:23:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683109385; x=1685701385; 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=hn2OrO3xAt0mIF0OPoFlaNSArATHVixACr0sQVsz+2w=; b=W8s7bPtUwG2/54fcCiISt+LZMg/OpCqMNWxCf44Wap8INKfzGCr3Js7k9WDe8psRdq eC1Y70YgdTxP21F/j0pm8VVTka/68QCMZXX9r/NJy9yRVWUZD7g17lBi4p8JmWY0DAAD Zek2+SQ9+gC9KGgEesSfcYslR1UbysMe2SUwq1WFusD4/YUmeKdfDWpGc7yr7hP6NOLU XuwCjc9uUrX8acUnkXiHnnLPKdgnvp12S39i1/Qr8D4kArafkQUIoGcL7Fj87qCUtJlA ZjWB66yW0BJpe7b4DF17lkjuPp9d/o6433lR9i6UjRIScwz1/bT64ubZmf4klospZQuE fHAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683109385; x=1685701385; 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=hn2OrO3xAt0mIF0OPoFlaNSArATHVixACr0sQVsz+2w=; b=b8ZQTqNlU1wejmaRkWfJlwfgCx2+SvrHnboQRyUux3ZpYSiFtQFX0d5pqGf7dMYBsR dwaODeq55b0H40AVqXRyMnNH6vMPOyhaYYLyW0KvddZgkNAkBrwDDlvgG8Pyb4EHL9zw AUnzSJ8rmoS27yoiF3qBWbc01y4C0DbE97qvnEmfcdj+wtAzu018+mSwagbquTOU68W2 oD5FlabAgA3fWQPIM6kG2l0MqvtLFXo/IdZRCKLuKaGYmpigQ9JKKw83cV/uvoBhwqPX dC5Y7wrIUyySJIPpirbv4zZ9Cklk9+++U4567TAsbeM79TxeC3pd9lkP8xeCOltcGWPW 99gA== X-Gm-Message-State: AC+VfDyXjH7EgFXU0bP5vUtSH15ddcviLjNepAaZtfJaOUnyFcpi/7hO eqi72TXvFF7VZtDO4Xp9p8Sv5jxf5hSthg2ZO2EhtPGB X-Google-Smtp-Source: ACHHUZ6ToTZ0jSwaqTqky7g+eSIXLXLCalb2PnMmmduNbm0eUn4mhBYqSm8WXbI42iEFfe8ZmwhikMBAKYS4CO9Mje0= X-Received: by 2002:a05:6512:114f:b0:4eb:4157:5704 with SMTP id m15-20020a056512114f00b004eb41575704mr478892lfg.29.1683109385108; Wed, 03 May 2023 03:23:05 -0700 (PDT) MIME-Version: 1.0 References: <20230203130539.12F0A1346D@imap2.suse-dmz.suse.de> In-Reply-To: <20230203130539.12F0A1346D@imap2.suse-dmz.suse.de> From: Richard Biener Date: Wed, 3 May 2023 12:22:51 +0200 Message-ID: Subject: Re: [PATCH] Speedup cse_insn To: Richard Biener Cc: gcc-patches@gcc.gnu.org, jeffreyalaw@gmail.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,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 Fri, Feb 3, 2023 at 2:06=E2=80=AFPM Richard Biener via Gcc-patches wrote: > > When cse_insn prunes src{,_folded,_eqv_here,_related} with the > equivalence set in the *_same_value chain it also searches for > an equivalence to the destination of the instruction with > > /* This is the same as the destination of the insns, we want > to prefer it. Copy it to src_related. The code below will > then give it a negative cost. */ > if (GET_CODE (dest) =3D=3D code && rtx_equal_p (p->exp, dest)) > src_related =3D p->exp; > > this picks up the last such equivalence and in particular any > later duplicate will be pruned by the preceeding > > else if (src_related && GET_CODE (src_related) =3D=3D code > && rtx_equal_p (src_related, p->exp)) > src_related =3D 0; > > first. This wastes cycles doing extra rtx_equal_p checks. The > following instead searches for the first destination equivalence > separately in this loop and delays using src_related for it until > we are about to process that, avoiding another redundant rtx_equal_p > check. > > I've came here because of a testcase with very large equivalence > lists and compile-time of cse_insn. The patch below doesn't speed > it up significantly since there's no equivalence on the destination. > > In theory this opens the possibility to track dest_related > separately, avoiding the implicit pruning of any previous > value in src_related. As is the change should be a no-op for > code generation. > > Bootstrapped and tested on x86_64-unknown-linux-gnu, queued for > stage1. I have pushed this now after re-bootstrapping and testing on x86_64-unknown-linux-gnu. Richard. > * cse.cc (cse_insn): Track an equivalence to the destination > separately and delay using src_related for it. > --- > gcc/cse.cc | 51 +++++++++++++++++++++++++++------------------------ > 1 file changed, 27 insertions(+), 24 deletions(-) > > diff --git a/gcc/cse.cc b/gcc/cse.cc > index 8fbda4ecc86..543cb1fe36f 100644 > --- a/gcc/cse.cc > +++ b/gcc/cse.cc > @@ -4614,6 +4614,7 @@ cse_insn (rtx_insn *insn) > rtx src_eqv_here; > rtx src_const =3D 0; > rtx src_related =3D 0; > + rtx dest_related =3D 0; > bool src_related_is_const_anchor =3D false; > struct table_elt *src_const_elt =3D 0; > int src_cost =3D MAX_COST; > @@ -5085,10 +5086,11 @@ cse_insn (rtx_insn *insn) > src_related =3D 0; > > /* This is the same as the destination of the insns, we want > - to prefer it. Copy it to src_related. The code below will > - then give it a negative cost. */ > - if (GET_CODE (dest) =3D=3D code && rtx_equal_p (p->exp, dest)) > - src_related =3D p->exp; > + to prefer it. The code below will then give it a negative > + cost. */ > + if (!dest_related > + && GET_CODE (dest) =3D=3D code && rtx_equal_p (p->exp, dest= )) > + dest_related =3D p->exp; > } > > /* Find the cheapest valid equivalent, trying all the available > @@ -5130,27 +5132,28 @@ cse_insn (rtx_insn *insn) > } > } > > - if (src_related) > + if (dest_related) > { > - if (rtx_equal_p (src_related, dest)) > - src_related_cost =3D src_related_regcost =3D -1; > - else > - { > - src_related_cost =3D COST (src_related, mode); > - src_related_regcost =3D approx_reg_cost (src_related); > - > - /* If a const-anchor is used to synthesize a constant that > - normally requires multiple instructions then slightly pr= efer > - it over the original sequence. These instructions are l= ikely > - to become redundant now. We can't compare against the c= ost > - of src_eqv_here because, on MIPS for example, multi-insn > - constants have zero cost; they are assumed to be hoisted= from > - loops. */ > - if (src_related_is_const_anchor > - && src_related_cost =3D=3D src_cost > - && src_eqv_here) > - src_related_cost--; > - } > + src_related_cost =3D src_related_regcost =3D -1; > + /* Handle it as src_related. */ > + src_related =3D dest_related; > + } > + else if (src_related) > + { > + src_related_cost =3D COST (src_related, mode); > + src_related_regcost =3D approx_reg_cost (src_related); > + > + /* If a const-anchor is used to synthesize a constant that > + normally requires multiple instructions then slightly prefer > + it over the original sequence. These instructions are likel= y > + to become redundant now. We can't compare against the cost > + of src_eqv_here because, on MIPS for example, multi-insn > + constants have zero cost; they are assumed to be hoisted fro= m > + loops. */ > + if (src_related_is_const_anchor > + && src_related_cost =3D=3D src_cost > + && src_eqv_here) > + src_related_cost--; > } > > /* If this was an indirect jump insn, a known label will really be > -- > 2.35.3