From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) by sourceware.org (Postfix) with ESMTPS id 7EDCE3858C2D for ; Fri, 4 Aug 2023 09:52:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7EDCE3858C2D 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-oi1-x233.google.com with SMTP id 5614622812f47-3a3efebcc24so1461644b6e.1 for ; Fri, 04 Aug 2023 02:52:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrull.eu; s=google; t=1691142763; x=1691747563; 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=YBtAIaZHz4hpDIAZK6dNhqTmvWhMl/mKpt1Epex6RR0=; b=HACeRLawQ2zZl5Zl73rOzsEdUZ7IhnqGDheRT7Y7r1wdSsqVXCEYK/iQfxcy4eKacJ F2e96zMHbX8mhroW/NrbVSfyq6Bi+qPVtbUFtFtv6lTPaNOUj8homav3Y0sTFUx8zWaE iXiIlC0qMoGx/30Ixi6+LGN11hMQtrNRc350j9l6QWqnnxE1fxmWu9pm7prZZ4GROHU3 TaaPl9kPNAI+QQJtu3OrZpnCXzoWSsBithS4YGgSDHq36t1t+xNpB4R8m9QMI8jKWrn6 6zA9AqO5JXuBI5ypox40EP+05ABy8DgJGUpHlhT7Vj9a+XJ0wbKaqzKbI7lwRo85aiid DxeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691142763; x=1691747563; 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=YBtAIaZHz4hpDIAZK6dNhqTmvWhMl/mKpt1Epex6RR0=; b=gULc2rBW7yMaIasigi+MYF2de4nm43FsyYzfgq1SKTFAaNFcI5nlv1V2QRdBb9HXNI 3TslVHacEjQyWiF0oPP+Vmo3OGRa4L7761+fthctDJYCEgrPI8q7K54q3+s8GHFRcMAC FWZoPKFn2q6qk0r7IS4Twe6oKjyfto93eEqL4z9YsU/by/wJ2NZHgbw9HrHqKNKNHgG7 91zuNff11NIrEuDEBEK9MkAN+NodUSxW1rLDXDpiTMf0yuA4CxvXLisAP/j3BvtE+FO2 h+BESSwH/NrykcES0rPoq0mAI2B+Z/DLwhBE6JvDezBXrdmygV8YhVVwo4YmGFP9aC1l 59ew== X-Gm-Message-State: AOJu0YyEhZR2MlUdE63o3e8DYLCBZkm3P0iA1ltHRsVdPZshHb3f9fV3 dYQr2KbgcWukEYjytmd0kO1QdaSlQAeLtfTgBaz8PA== X-Google-Smtp-Source: AGHT+IHky3DO3SCfnAWJV8X2RFKMzhPe9qQeVRPIplfyMX8O/JWQp2u+jcOyJMiwG/hsGtUItpcKpf3keIf5KioPVnQ= X-Received: by 2002:a05:6808:169e:b0:3a7:3ab9:e590 with SMTP id bb30-20020a056808169e00b003a73ab9e590mr1753644oib.9.1691142762721; Fri, 04 Aug 2023 02:52:42 -0700 (PDT) MIME-Version: 1.0 References: <3c1f0f8a-34ed-abb2-8a49-3083a2cc55d2@gmail.com> <61c9b9c2-f52e-2b4e-6d02-62c991603c39@gmail.com> <64233838-fe5e-458d-1eaf-3025b5448d85@rivosinc.com> <91c12503-c288-5b81-8941-cc62bab2ee98@gmail.com> <73dc8b97-7a7b-d9a0-2e8e-b4a5aaa3ee93@rivosinc.com> <40176a5c-382d-809d-a4b1-06c6541c3670@gmail.com> In-Reply-To: From: Manolis Tsamis Date: Fri, 4 Aug 2023 12:52:06 +0300 Message-ID: Subject: Re: RISC-V: Folding memory for FP + constant case To: Jeff Law Cc: Vineet Gupta , Philipp Tomsich , Jivan Hakobyan , gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.8 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 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: Hi all, It is true that regcprop currently does not propagate sp and hence leela is not optimized, but from what I see this should be something we can address. The reason that the propagation fails is this check that I have added when I introduced maybe_copy_reg_attrs: else if (REG_POINTER (new_reg) !=3D REG_POINTER (old_reg)) { /* Only a single instance of STACK_POINTER_RTX must exist and we cannot modify it. Allow propagation if REG_POINTER for OLD_REG matches and don't touch ORIGINAL_REGNO and REG_ATTRS. */ return NULL_RTX; } To be honest I did add this back then just to be on the safe side of whether a mismatch in REG_POINTER after propagation would be an issue (since the original regcprop had caused enough problems). I see two ways to solve this and make fmo able to optimize leela as well: 1) Remove the REG_POINTER check in regcprop if that is safe. My understanding is that REG_POINTER is used as a hint and there would be no correctness issues. 2) Mark the corresponding registers with REG_POINTER. I'm not sure where that is supposed to happen. Since the instructions look like this: (insn 113 11 16 2 (set (reg:DI 15 a5 [226]) (reg/f:DI 2 sp)) 179 {*movdi_64bit} (nil)) I assume that we'd want to mark a5 as REG_POINTER anyway (which is not), and in that case propagation would work. On the other hand if there's no correctness issue w.r.t. REG_POINTER and regcprop then removing the additional check would increase propagation opportunities in general which is also good. Thanks, Manolis On Wed, Aug 2, 2023 at 2:52=E2=80=AFAM Jeff Law wro= te: > > > > On 8/1/23 17:38, Vineet Gupta wrote: > >> > >> Also note that getting FP out of the shift-add sequences is the other > >> key goal of Jivan's work. FP elimination always results in a > >> spill/reload if we have a shift-add insn where one operand is FP. > > > > Hmm, are you saying it should NOT be generating shift-add with SP as > > src, because currently thats exactly what fold FP offset *is* doing and > > is the reason it has 5 less insns. > We should not have shift-add with FP as a source prior to register > allocation because it will almost always generate spill code. > > > jeff