From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) by sourceware.org (Postfix) with ESMTPS id 503AC3858D28 for ; Tue, 1 Aug 2023 20:16:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 503AC3858D28 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-pg1-x536.google.com with SMTP id 41be03b00d2f7-55b1238cab4so3768544a12.2 for ; Tue, 01 Aug 2023 13:16:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690920967; x=1691525767; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Y9JTQl1+oa0c0z0oMIk7BQp9UnjUTfIpE0ZguOqSrjk=; b=UXZiBH8Z77fGeHriwXYnm70wQPnewikJPmjXWotkSD1uBUppCxqk2UCwmfG3kOOKPk JXoyabFs8LW8+J2DJpsjB5/vFetLus3OfDVxF+Vj7C0LBET2tcKBrmeX9HLv+Z3fuiHZ 0EWCwXgEdNd60aoc5xmv4Ia50o5UxEP9pex3ZolgugCKth1jzRNkY3YV/we656Kv2+YL 0hR1xEU+MeFxkTXiQtUU/czYzDYSK5kL3uLSIFz/1NRL1aoEoGLOTT4B5jbjoPynjIeF jqVstSruGQqhVZAgzkFDPUvBtEaQc84Kl9wkWbEHC2GEJLWf/Q24Lh0szqm2ugt5CNXb 5EOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690920967; x=1691525767; h=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=Y9JTQl1+oa0c0z0oMIk7BQp9UnjUTfIpE0ZguOqSrjk=; b=IsWputsJOMoYhAHbZAdnxcoDBVliNnpnpgl0dGFrjtVonNQQa3jv+B5k4uKWmO6mEF 7Uu2uUee76jGfbAcSHaaCMXGuTNytJE38qnFPD567iHDUmE16dagykScusBMHzqqt4Ig MBUyzRUwfw+saZKvsqfI1O4BLUo4uzg4+i4jLs0+51iwRQ64Rl7o4bXpoArEkRvQvQ+3 7oRJAPH7OveOKi6yQxfS5mXmyU9GvpxoO1tqxSkkxkH+jJBGCAkET5epyReq3MG9Ic1u QHMYRUuHUTKLuu1gGg1IlRdwITY5QVTVjlo/EpJZNwVn9ymFNPhciYZc6O2ilbrr9o0y YkCg== X-Gm-Message-State: ABy/qLYq01kHi4ohB3S8D04N1sQe17rQz9jV3opILB9/FVCDBjDirmg0 yl+FGieg8D7/WYGatK3QB2PAdD52or0gUJu1ZKs= X-Google-Smtp-Source: APBJJlFNXiPB5334hXUKSNYeOxb8nRS5Xzp+mYi98mCAkrTaNuTnjmNqBthr/94mlUVdd54IbaBZRIeShVvTNqY2bMo= X-Received: by 2002:a17:90a:640f:b0:259:10a8:2389 with SMTP id g15-20020a17090a640f00b0025910a82389mr11189577pjj.35.1690920967280; Tue, 01 Aug 2023 13:16:07 -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> In-Reply-To: <64233838-fe5e-458d-1eaf-3025b5448d85@rivosinc.com> From: Jivan Hakobyan Date: Wed, 2 Aug 2023 00:16:01 +0400 Message-ID: Subject: Re: RISC-V: Folding memory for FP + constant case To: Vineet Gupta Cc: Jeff Law , gcc-patches@gcc.gnu.org Content-Type: multipart/alternative; boundary="000000000000991d5c0601e237c8" X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,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: --000000000000991d5c0601e237c8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you for your effort. I had evaluated only in intrate tests. I am glad to see the same result on Leela. On Tue, Aug 1, 2023 at 11:14=E2=80=AFPM Vineet Gupta = wrote: > > > On 7/25/23 20:31, Jeff Law via Gcc-patches wrote: > > > > > > On 7/25/23 05:24, Jivan Hakobyan wrote: > >> Hi. > >> > >> I re-run the benchmarks and hopefully got the same profit. > >> I also compared the leela's code and figured out the reason. > >> > >> Actually, my and Manolis's patches do the same thing. The difference > >> is only execution order. > > But shouldn't your patch also allow for for at the last the potential > > to pull the fp+offset computation out of a loop? I'm pretty sure > > Manolis's patch can't do that. > > > >> Because of f-m-o held after the register allocation it cannot > >> eliminate redundant move 'sp' to another register. > > Actually that's supposed to be handled by a different patch that > > should already be upstream. Specifically; > > > >> commit 6a2e8dcbbd4bab374b27abea375bf7a921047800 > >> Author: Manolis Tsamis > >> Date: Thu May 25 13:44:41 2023 +0200 > >> > >> cprop_hardreg: Enable propagation of the stack pointer if possible > >> Propagation of the stack pointer in cprop_hardreg is currenty > >> forbidden in all cases, due to maybe_mode_change returning NULL. > >> Relax this restriction and allow propagation when no mode change is > >> requested. > >> gcc/ChangeLog: > >> * regcprop.cc (maybe_mode_change): Enable stack pointer > >> propagation. > > I think there were a couple-follow-ups. But that's the key change > > that should allow propagation of copies from the stack pointer and > > thus eliminate the mov gpr,sp instructions. If that's not happening, > > then it's worth investigating why. > > > >> > >> Besides that, I have checked the build failure on x264_r. It is > >> already fixed on the third version. > > Yea, this was a problem with re-recognition. I think it was fixed by: > > > >> commit ecfa870ff29d979bd2c3d411643b551f2b6915b0 > >> Author: Vineet Gupta > >> Date: Thu Jul 20 11:15:37 2023 -0700 > >> > >> RISC-V: optim const DF +0.0 store to mem [PR/110748] > >> Fixes: ef85d150b5963 ("RISC-V: Enable TARGET_SUPPORTS_WIDE_INT= ") > >> DF +0.0 is bitwise all zeros so int x0 store to mem can be > >> used to optimize it. > > [ ... ] > > > > > > So I think the big question WRT your patch is does it still help the > > case where we weren't pulling the fp+offset computation out of a loop. > > I have some numbers for f-m-o v3 vs this. Attached here (vs. inline to > avoid the Thunderbird mangling the test formatting) > --=20 With the best regards Jivan Hakobyan --000000000000991d5c0601e237c8--