From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) by sourceware.org (Postfix) with ESMTPS id 7B51D3858D32 for ; Mon, 12 Jun 2023 19:32:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7B51D3858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com Received: by mail-pl1-x636.google.com with SMTP id d9443c01a7336-1b3b974fffeso14818555ad.1 for ; Mon, 12 Jun 2023 12:32:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20221208.gappssmtp.com; s=20221208; t=1686598352; x=1689190352; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=jJLVA8Mto0O5Xva+t0cU6RV5CskxROLhUZ2VAO3eQeU=; b=cU6qtcLZPnY2oyFdr6yRTellkxxNX1HRFQhRqJKh6gYN4wWTgLWTG/8RWvY4oy9E2z +i0bdI0d2DjzAY75X7sxfE4VvtAgnxb/T1Nql1fly2A82GpPA2EvInyQxFjafAG2SEko EMbiv8A9kI8N8iaa6dl1klN70UrgSO/NS86gg7CL4Rp0Pyi7NPMFolcdzuE8Y2pWvSRa 9MwdfuVDWDLWQ90opXJBL1QBdhsJKosCW3xsskZ719TgGNfBmD3MNT5HnIlt6uR4Y8I6 mTOpTEcOxhlpBViMgfcJkWuGLb1OvlBxhosP0c8C5dqWPaRJNps27G3Nl7ATBKxshlmO mDvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686598352; x=1689190352; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jJLVA8Mto0O5Xva+t0cU6RV5CskxROLhUZ2VAO3eQeU=; b=Jo5jJRGP8s8ikItcIb5kFYIKo2YMRlevU8/3D2crDgftKyQQcXY2qS9IR3tSNlpKiW I5bUjOBPy1MdcKC8VXm2HTD/vAQvtcZg7njy/eMcj7UbYjFLINn/0BB7Q5JCOf9rMwbB 3mcdfYhq4MYgfj0HVyYag2mB6tym8M2nifRouckJfrVqTGOemM8GQeqEP9MbZeSDyIb5 14J+SsG4tlLwuVNAtxPEDowjPMP6KF1/VShHH2Cs3ENZjXtLtZ5BF4WJEddVyfjJcE6i gpOi2Zufg6ZidTmbHlZDTTv7jACIl46GM1Bmj6VaXEV1SGcftZo3H87v7K8Og5Zjf+Qx RVDQ== X-Gm-Message-State: AC+VfDxjH99Lci8bLDgbps5g9rvWukGyj0wcuzM28DdxWo0k8jxZDg6X 0cOWJx7o534RBDAD/jYjCr3VUg== X-Google-Smtp-Source: ACHHUZ59leFEuq395nb9MkP2SKNnuq5KW8IsBHWPZtxpNoVzoQITWqvt9MLNO+Mu6EttYPDA9vcJ5g== X-Received: by 2002:a17:902:b213:b0:1af:b678:5168 with SMTP id t19-20020a170902b21300b001afb6785168mr6647134plr.67.1686598352447; Mon, 12 Jun 2023 12:32:32 -0700 (PDT) Received: from [192.168.50.116] ([71.202.114.183]) by smtp.gmail.com with ESMTPSA id nd14-20020a17090b4cce00b002565a84c848sm58055pjb.43.2023.06.12.12.32.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jun 2023 12:32:32 -0700 (PDT) Message-ID: <00e36310-368d-3435-a4a2-b8afbd6b3bc2@rivosinc.com> Date: Mon, 12 Jun 2023 12:32:30 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: Followup on PR/109279: large constants on RISCV To: Jeff Law Cc: gcc@gcc.gnu.org, Kito Cheng , Palmer Dabbelt , gnu-toolchain , pinskia@gmail.com, GCC Patches References: <09f944a2-1123-75e3-ce2f-2080df94c964@rivosinc.com> <80218276-fc3c-032b-eaa7-0a4b0e8a859f@gmail.com> Content-Language: en-US From: Vineet Gupta In-Reply-To: <80218276-fc3c-032b-eaa7-0a4b0e8a859f@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,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: Hi Jeff, Thx for the detailed explanation and insight. On 6/7/23 16:44, Jeff Law wrote: >> With 2e886eef7f2b, define_insn_and_split "*mvconst_internal" recog() >> kicks in during cse1, eliding insns for a const_int. >> >>     (insn 7 6 8 2 (set (reg:DI 137) >>          (const_int [0x1010101])) {*mvconst_internal} >>          (expr_list:REG_EQUAL (const_int [0x1010101]))) >>     [...] >> >>     (insn 11 10 12 2 (set (reg:DI 140) >>          (const_int [0x1010101_00000000])) {*mvconst_internal} >>          (expr_list:REG_EQUAL (const_int  [0x1010101_00000000]) )) > Understood.  Not ideal, but we generally don't have good ways to limit > patterns to being available at different times during the optimization > phase.  One thing you might want to try (which I thought we used at > one point) was make the pattern conditional on cse_not_expected.  The > goal would be to avoid exposing the pattern until a later point in the > optimizer pipeline.  It may have been the case that we dropped that > over time during development.  It's all getting fuzzy at this point. Gave this a try and it seems to fix Andrew's test, but then regresses the actual large const case: 0x1010101_01010101 : the mem to const_int transformation was being done in cse1 which no longer happens and the const pool from initial expand remains all the way into asm generated. I don't think we want to go back to that state > >> >> Eventually split1 breaks it up using same mvconst_internal splitter, >> but the cse opportunity has been lost. > Right.  I'd have to look at the pass definitions, but I suspect the > splitting pass where this happens is after the last standard CSE pass. > So we don't get a chance to CSE the constant synthesis. Yep split1 and friends happen after cse1 and cse2. At -O2 gcse doesn't kick in and if forced to, it is currently limited in what it can do more so given this is post reload. > >> *This is a now a baseline for large consts handling for RV backend >> which we all need to be aware of*. > Understood.  Though it's not as bad as you might think :-)  You can > spend an inordinate amount of time improving constant synthesis, > generate code that looks really good, but in the end it may not make a > bit of different in real performance.  Been there, done that.  I'm not > saying we give up, but we need to keep in mind that we're often better > off trading a bit on the constant synthesis if doing so helps code > where those constants get used. Understood :-) I was coming to same realization and this seems like a good segway into switching topic and investigating post reload gcse for Const Rematerialization, another pesky issue with RV and likely to have bigger impact across a whole bunch of workloads. >> FWIW, IRA for latter case only, emits additional REG_EQUIV notes >> which could also be playing a role. > REG_EQUAL notes get promoted to REG_EQUIV notes in some cases. And > when other equivalences are discovered it may create a REG_EQUIV note > out of thin air. > > The REG_EQUIV note essentially means that everywhere the register > occurs you can validly (from a program semantics standpoint) replace > the register with the value.  It might require reloading, but it's a > valid semantic transformation which may reduce register pressure -- > especially for constants that were subject to LICM. > > Contrast to REG_EQUAL which creates an equivalence at a particular > point in the IL, but the equivalence may not hold elsewhere in the IL. Ok. From reading gccint it seems REG_EQUIV is a stronger form of equivalence and seems to be prefered by post reload passes, while REG_EQUAL is more of use in pre-reload. >   I would also look at reload_cse_regs which should give us some > chance at seeing the value reuse if/when IRA/LRA muck things up. I'll be out of office for the rest of week, will look into this once I'm back. Thx, -Vineet