From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) by sourceware.org (Postfix) with ESMTPS id 0CC6F3858C66 for ; Tue, 25 Jul 2023 11:51:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0CC6F3858C66 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-lj1-x234.google.com with SMTP id 38308e7fff4ca-2b9338e4695so79914701fa.2 for ; Tue, 25 Jul 2023 04:51:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690285870; x=1690890670; 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=CCurmsSeQjTtqDdr0NXRHift87m2G2ONlz7j+BoCVxY=; b=mCMRvcrqh4HIn10JY++SolkPDpr32QOApbQe2i/PlWEgvLV7PhIy5zufMPouOMrpww Znzr+vZ5E2/3+gyEI8zMziPn0wukSKY+8IvvVxE+QR95zJ2V9GSSoVB9024iGceZRmLb +SK4A2VNs+KWnnzTkvjoHFflh3Jgie5BET+I++2lQjxchQIcb5AIn2L1YW//Bc5EiGiF +DCKaMYurFv3+EozOaj6r/lKWHqgV2k32yIGCiIRORNzgcmSwPxVETiY9E+BVl8Ml+Ra W9783fC0WxSFSQtK4rReDirQ4qm4xYFvSJoZJTOFE8WDx4/0Y4dvyNfmEriDvNzusOdK CGUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690285870; x=1690890670; 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=CCurmsSeQjTtqDdr0NXRHift87m2G2ONlz7j+BoCVxY=; b=FYyQ8PSrPIYvgbbi+xDoBl+7fxOC8kIrfwv8FyGb2rRmrINbg+lJvzIvcVHzFaYSDv F7Sm+B7GTJyfH6gbU9QLK8vGnf0vkTSPWgBykZHHvalt2F/6Mfk1CGHt+GPjqzYN3fHz vPRhtMpDeP+9ew81yOXQUnjbeJM2k3umwu3fTs5NSb4LrVPnJHK6ppJez35Gno8fTUMK 8tB9ZiFgjbozQjc8wgcCpVbIEjf+ByzLwCYdBnnLfVvnsneH+fYp2IaV/Bk+aQbUUEEx GRRqiy7poqltdFOSW9Vif6puw9weeFApDokknQTtm1jIB4VKKmUyIKFq9/7rjg3mA5kw 6tEA== X-Gm-Message-State: ABy/qLa9Al+qkEIouqWJ6jen8yxFXWWeXA7wGK0Kd98KVE2wQhATGAR4 y596K7QuyjJogwb+Qr8XcqcqHOU3cXWKIhcxOyw= X-Google-Smtp-Source: APBJJlHMHNE6zW5kWfAAyiQmfJHsPPNvGz+0u6oPo1V7ALOJia9R/siv9kSOKUTByIerioA5+E7YlJeUPpohmMLEomE= X-Received: by 2002:a05:651c:151:b0:2b6:e618:b5a0 with SMTP id c17-20020a05651c015100b002b6e618b5a0mr8010273ljd.6.1690285869330; Tue, 25 Jul 2023 04:51:09 -0700 (PDT) MIME-Version: 1.0 References: <004c01d9beeb$98c6fcf0$ca54f6d0$@nextmovesoftware.com> In-Reply-To: <004c01d9beeb$98c6fcf0$ca54f6d0$@nextmovesoftware.com> From: Richard Biener Date: Tue, 25 Jul 2023 13:50:27 +0200 Message-ID: Subject: Re: [PATCH] PR rtl-optimization/110587: Reduce useless moves in compile-time hog. To: Roger Sayle Cc: gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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 Tue, Jul 25, 2023 at 1:31=E2=80=AFPM Roger Sayle wrote: > > > This patch is the third in series of fixes for PR rtl-optimization/110587= , > a compile-time regression with -O0, that attempts to address the underlyi= ng > cause. As noted previously, the pathological test case pr28071.c contain= s > a large number of useless register-to-register moves that can produce > quadratic behaviour (in LRA). These move are generated during RTL > expansion in emit_group_load_1, where the middle-end attempts to simplify > the source before calling extract_bit_field. This is reasonable if the > source is a complex expression (from before the tree-ssa optimizers), or > a SUBREG, or a hard register, but it's not particularly useful to copy > a pseudo register into a new pseudo register. This patch eliminates that > redundancy. > > The -fdump-tree-expand for pr28071.c compiled with -O0 currently contains > 777K lines, with this patch it contains 717K lines, i.e. saving about 60K > lines (admittedly of debugging text output, but it makes the point). > > > This patch has been tested on x86_64-pc-linux-gnu with make bootstrap > and make -k check, both with and without --target_board=3Dunix{-m32} > with no new failures. Ok for mainline? > > As always, I'm happy to revert this change quickly if there's a problem, > and investigate why this additional copy might (still) be needed on other > non-x86 targets. @@ -2622,6 +2622,7 @@ emit_group_load_1 (rtx *tmps, rtx dst, rtx orig_src, tree type, be loaded directly into the destination. */ src =3D orig_src; if (!MEM_P (orig_src) + && (!REG_P (orig_src) || HARD_REGISTER_P (orig_src)) && (!CONSTANT_P (orig_src) || (GET_MODE (orig_src) !=3D mode && GET_MODE (orig_src) !=3D VOIDmode))) so that means the code guarded by the conditional could instead be transformed to src =3D force_reg (mode, orig_src); ? Btw, the || (GET_MODE (orig_src) !=3D mode && GET_MODE (orig_src) !=3D V= OIDmode) case looks odd as in that case we'd use GET_MODE (orig_src) for the move ... that might also mean we have to use force_reg (GET_MODE (orig_src) =3D=3D VOIDmode ? mode : GET_MODE (orig_src), orig_src)) Otherwise I think this is OK, as said, using force_reg somehow would improve readability here I think. I also wonder how the else if (GET_CODE (src) =3D=3D CONCAT) case will ever trigger with the current code. Richard. > > 2023-07-25 Roger Sayle > > gcc/ChangeLog > PR middle-end/28071 > PR rtl-optimization/110587 > * expr.cc (emit_group_load_1): Avoid copying a pseudo register in= to > a new pseudo register, i.e. only copy hard regs into a new pseudo= . > > > Thanks in advance, > Roger > -- >