From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) by sourceware.org (Postfix) with ESMTPS id 036533858D28 for ; Thu, 29 Sep 2022 07:45:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 036533858D28 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-ej1-x62f.google.com with SMTP id sb3so1030461ejb.9 for ; Thu, 29 Sep 2022 00:45:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=lJi5Ynhf8uHx45dZhUMhXe9q5GbPwzph0sJwwKkOdcE=; b=DJ7S4iXRLtUh/tbbXXh7ysxr27OJCq3tBeuAwkdS/ojkcyNaXfDgF/5n95U39RBI1f 19T1REhVtFZd6iGX6TKd1x5MBdSoRz6Lp8jxD+zo1C3AK6xXa5h3QdtqFSD2KaPOiaoP GgbY0Vs0eam6e58MAfG1RDqEu24MUU7k+GdpbDUZZjJuEA+56R+gCMZXG4VOLYljBe6e zx3FPoESyEhbfE2BElWgil5yEb8dRqWbd0bN9DYI2gnTiLfvZt0clKCIVfNBwDOaUsgb 2D+WhhaupuZSLlMVOUh/uGAcA3lWBfhQB6h0HiKMBJARvQuKdnekqyu5jvIXd8BgguN2 wrSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=lJi5Ynhf8uHx45dZhUMhXe9q5GbPwzph0sJwwKkOdcE=; b=iopbrxMtCvQb1goo3SFpuiYiqiZIg8aD8GvKH5mMGdai9I5M4ZmFV4uxMO/zV4c4ek mTicUmjTKFurLyQsAIEoP8fhDDtEZyaSbIcfQIY0T4XAHRpqmIKnoXdEhmM2jAELd4i5 PxPPqVTpY19atGJNaxR+bQKjdpaUPsSDzNxrh/8Ad6oyh4V+boFvz+j3AzQguukhcpEU zRvfF/1CgJOMXzfy6KSPHPvwxFtuSLcdLjIZ3atwoI9ruCZ1vLGtuACQZkVpwbIX9EHS TjWQCD1hLPqG7zI352vOAHPgpz3Fmp3P/6L0KXRjgbiwPdjvAPo/GI6sgvtl2nuu9xzm DS2A== X-Gm-Message-State: ACrzQf1quNjYE0P9tEqpbFjxfu1ytXGAvtHu5ugopIRiJMhJ2etifjN4 Z3IghAoaEbubmLv+cCbg2NkqplY9Vdr6TP8sPqA= X-Google-Smtp-Source: AMsMyM4rFmcbBJOm5uEYPeWHlgkjo28M4BsYBFHN+0p8kpa2AH8Z3QQieymtSe7eN7VeAAYji4z9+xHxHbRaznZfwKs= X-Received: by 2002:a17:907:968f:b0:782:6a9d:33fb with SMTP id hd15-20020a170907968f00b007826a9d33fbmr1577187ejc.754.1664437504571; Thu, 29 Sep 2022 00:45:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Thu, 29 Sep 2022 09:44:52 +0200 Message-ID: Subject: Re: [RFA] Avoid unnecessary load-immediate in coremark To: Jeff Law Cc: gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.2 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 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, Sep 27, 2022 at 9:54 PM Jeff Law wrote: > > > This is another minor improvement to coremark. I suspect this only > improves code size as the load-immediate was likely issuing with the ret > statement on multi-issue machines. > > > Basically we're failing to utilize conditional equivalences during the > post-reload CSE pass. So if a particular block is only reached when a > certain condition holds (say for example a4 == 0) and the block has an > assignment like a4 = 0, we would fail to eliminate the unnecessary > assignment. conditional equivalences on RTL - ick ;) I'm not familiar with RTL pattern matching so somebody else has to comment on that, but + /* If this is not the first time through, then + verify the source and destination match. */ + else if (dest == XEXP (cond, 0) && src == XEXP (cond, 1)) + ; shouldn't you restrict dest/src somehow? It might be a MEM? The way you create the fake insn suggests only REG_P dest are OK (not SUBREGs for example?)? Should you use rtx_equal_p (not using that possibly exempts MEM, but being more explicit would be nice). Should you restrict this to MODE_INT compares? Richard. > > So the way this works, as we enter each block in reload_cse_regs_1 we > look at the block's predecessors to see if all of them have the same > implicit assignment. If they do, then we create a dummy insn > representing that implicit assignment. > > > Before processing the first real insn, we enter the implicit assignment > into the cselib hash tables. This deferred action is necessary > because of CODE_LABEL handling in cselib -- when it sees a CODE_LABEL it > wipes state. So we have to add the implicit assignment after processing > the (optional) CODE_LABEL, but before processing real insns. > > > Note we have to walk all the block's predecessors to verify they all > have the same implicit assignment. That could potentially be expensive, > so we limit it to cases where there are only a few predecessors. For > reference on x86_64, 81% of the cases where implicit assignments can be > found are for single predecessor blocks. 96% have two preds, 99.1% have > 3 preds, 99.6% have 4 preds, 99.8% have 5 preds and so-on. While there > were cases where all 19 preds had the same implicit assignment capturing > those cases just doesn't seem terribly important. I put the clamp at 3 > preds. If folks think it's important, I could certainly make that a > PARAM. > > > Bootstrapped and regression tested on x86. Bootstrapped on riscv as well. > > > OK for the trunk? > > > Jeff > >