From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) by sourceware.org (Postfix) with ESMTPS id E86F13858D1E for ; Sat, 5 Aug 2023 09:27:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E86F13858D1E 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-pg1-x534.google.com with SMTP id 41be03b00d2f7-563df158ecaso1992339a12.0 for ; Sat, 05 Aug 2023 02:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrull.eu; s=google; t=1691227673; x=1691832473; 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=qjhFxBkowQIgiSEh5aQmrpWx3pZrsh1RaiZe8URGJ/E=; b=bhtbGwfVSIIhkNPsGJ0CpHiQIAsR4+2pfPsfZyaPvsR/sfiPogzpDa3Xf2bFVVbbnI 8QllDR8uhIy1mZ8NzvuCH4xNa/vOLryMtkkl0p167MiJhwrFnDVCFkAAsWKAt7ibnueE yERf7MoB3koVirgZx78K9/G8C1nczEUAqdJgPCZWfKjSuSC6vw2fwvjqvi2XdbIQ1EJ6 /xchpv9Sv9xMxpSUoNXj1aaste+sOAqv04rplWo8/51GkhwbHGnTg6BMm2e2nl4h1vW/ zpXGy+7KgeVW1sH2LmVOA+h+QkbwR7993ImJD+rdv2mHAjnCWmgK7DElZyFrNsgOnPqm EMow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691227673; x=1691832473; 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=qjhFxBkowQIgiSEh5aQmrpWx3pZrsh1RaiZe8URGJ/E=; b=RZFpkQkkoKxI5jQdNMrIEwTF3/nnXq4SIFhHZnEUU8jdjyECwJZB6Tw23Fu9i2vlDr fmP+73NVRrcybQyVSNJFaH7rRpDmYYceEaph/i5FWO+Bx7SGl3trKrrUW1eIKFFrRvtY kuhdjv73t1vtVjH2T63qZ+YHcrb0K/6Et6uxjphn0GHMv+pDT9k9fG6auOPh65YenXgh ptTdW2BYc2OfaSzde36h+BvS/N1YX9uS+jH2pF3dbgzV2JTCljTfmdCK421mUc05EuMo mk0bm5gCXxtgDriHCH9+ZxO3+dICEOMz6JAJ38HN8D+oNv2JfboUG1xwYXmFA8yWcxHw PxRg== X-Gm-Message-State: AOJu0YzgVUP2DOam5AUFFZaIxoZtWLLHgzHZ3MiE55thht2DTuJyuIOu jzsaFOX62oHTIP0hoB2brCWswpg5nuIbi2bwv7kZXw== X-Google-Smtp-Source: AGHT+IFAEBWK7fgA1TRj07en8EHTAX/gajiKj/RjN0hOO06YIANH/FA/hcG9ixajepsBrvK5fJoV88D2Gki3RZFO/Ps= X-Received: by 2002:a17:90b:148:b0:262:ec13:d3a with SMTP id em8-20020a17090b014800b00262ec130d3amr4435657pjb.28.1691227672838; Sat, 05 Aug 2023 02:27:52 -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: Sat, 5 Aug 2023 12:27:16 +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.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,KAM_LINEPADDING,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 Jeff, Thanks for all the info! Then I'll prepare/test a patch that removes this regcprop limitation and send it out. I have already tested that this change is enough to make fmo optimize leela as well. Manolis On Fri, Aug 4, 2023 at 7:23=E2=80=AFPM Jeff Law wro= te: > > > > On 8/4/23 03:52, Manolis Tsamis wrote: > > 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 c= annot > > 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). > No worries. Obviously not propagating is the safe thing to do and if we > find notable missed cases we can always refine the existing code like > we're considering now. > > > > > I see two ways to solve this and make fmo able to optimize leela as wel= l: > > 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. > REG_POINTER is meant to be conservatively correct. If REG_POINTER is > set, then the register must be a pointer to a valid memory location. If > REG_POINTER is not set, then it may or may not point to a valid memory > location. sp, fp, ap are by definition pointers and thus have > REG_POINTER set. > > With that definition we can safely copy propagate away an sp->gpr copy > from a REG_POINTER standpoint. > > > > > > > > > > > > 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. > I'd strongly recommend against that. The problem is the destination > register might have been used in another context as an index register. > We've fixed a few bugs in this space through the years I suspect there > may be others lurking. You can't directly set that up in C code, but > once you get down to RTL it can happen. > > > > 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. > I think you can safely remove this limitation. > > jeff