From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) by sourceware.org (Postfix) with ESMTPS id BC2083858CD1 for ; Wed, 26 Jul 2023 03:31:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BC2083858CD1 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-il1-x131.google.com with SMTP id e9e14a558f8ab-345d3c10bdfso25831045ab.2 for ; Tue, 25 Jul 2023 20:31:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690342304; x=1690947104; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=giG7g+xVY+IRCk0P8UeFtNIhhFcHEwEnwBLnu8yapcc=; b=HlfMEDPHFvSFUagedSC77jFLat5MGII0ih1y3cG64LTCoPhZ6MYcgvV1W3Ei0CiKBc LgQjNBI9cSeRz8tJl6w0S7ohoifoDhTAaQl5vVZNYIwDK1mjCbbn9uJpyf+9E+j4wOv1 bZwjuICdHdfCfx/j08owtPqFq+/G9HQzyY7kA872VqrvaZxEkypat5H1OI5FFWUeJ73+ EFWBk2bHy5azuDEx65Dcz0xmLmykl2SSJ2W5bcH5CymwiIT+lvWwSaoQDWmHI6YLpLI7 eQmrUn/Ov1KFWX9ZrOVa+RIRUqwfBENKf4QTkf1NV3GOojmL7TWFV0vXIAqUqfbG1TaV L2oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690342304; x=1690947104; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=giG7g+xVY+IRCk0P8UeFtNIhhFcHEwEnwBLnu8yapcc=; b=BEkKfm6a5tV8WyE7pxTMustZ3R/fTd5D8zwumyaBQekhMjCPGK98w8FZ6+cVwFE2bO qNa72VmzGuxoCb6XT5Ii6G0578xdbVHDMaUYL6qkKOlyhnE/YJNdHFk1eiBW8XFaOW0e OU8ey3dQrKnIXSAvTfVvqB5vXVBUn0e1kXPLk/Odmlf3MBR6MN50DcwtiVyIpE+qIuV3 Lj6y9VP6bI1/XBXSCdfUvYVw2MfbUj9WxbZzIFCB79RxS01koQfc2ecKh6fkchKnUr7d 3XNKPIfSzSBFI1mKFduS5Y/q8hJbsIIn9H6ehssa7OHkZZxNpJv5VswZ4ujWtYe8sqNP eIog== X-Gm-Message-State: ABy/qLZIQTFeEnUQbgQwLPUvSVDHWBbGDGMaQNEOU1xctgdrCesyQChi PCU/VTmRpi8L2825k9EMe1c= X-Google-Smtp-Source: APBJJlHaXBAoepIH9+CDwKHrbXkR/Tg3yNB0WQgEivCP4uUur6zzuoZMOERnFIiTXQz+EFNp6+0+2Q== X-Received: by 2002:a05:6e02:de8:b0:345:cf9f:abbc with SMTP id m8-20020a056e020de800b00345cf9fabbcmr875581ilj.7.1690342303799; Tue, 25 Jul 2023 20:31:43 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id b3-20020a170903228300b001b8ab115ce4sm11844402plh.278.2023.07.25.20.31.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 25 Jul 2023 20:31:43 -0700 (PDT) Message-ID: <61c9b9c2-f52e-2b4e-6d02-62c991603c39@gmail.com> Date: Tue, 25 Jul 2023 21:31:42 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: RISC-V: Folding memory for FP + constant case Content-Language: en-US To: Jivan Hakobyan Cc: gcc-patches@gcc.gnu.org References: <3c1f0f8a-34ed-abb2-8a49-3083a2cc55d2@gmail.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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: 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. Jeff