From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) by sourceware.org (Postfix) with ESMTPS id B8BC138381DF for ; Mon, 28 Nov 2022 16:15:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B8BC138381DF 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-pj1-x1033.google.com with SMTP id x13-20020a17090a46cd00b00218f611b6e9so10626422pjg.1 for ; Mon, 28 Nov 2022 08:15:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; 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=9LgGzqJOfCxl346ozwBy15gxSGiU/dU10CY9dV2HFLc=; b=p7mIrH1sQk064aI5TscDvRdLZeYbSKVazXKj7IBoq+QaWSXvo8/KTAuoen4tmD1M+x BOqYA4X3W0CAFNiNw1HseZVjSZrthYsv7VtWI++40O95wsi4p/pusSTpvu/UfhXZiI2e 5txPA2cKXjsbAkVgZFVs7LcA0LUOwUe1Sz8GB5sUzIm6W6EqkMi1WvN97oNiGMdcpC9n ggqqaCx52gvZBHvFLUtmG2oMY0ObQxBGVilwONOSmMOQZ2J8F0FwxEn9BKG5vZneXNns VavVbY1sUd3K3wo7cc8su7Ky5V7L9xEicDrDH8CYrYZ11xluvW7aApcxGVJFAIj1J59d XR0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=9LgGzqJOfCxl346ozwBy15gxSGiU/dU10CY9dV2HFLc=; b=Hm8/NDGObYHA0J6nLYWtJtVkHRgFTjS5SWhM14EJGreumV2GNfhp0QjQJObhVZjKYB 1Orj+3h+PPdv2i3okB0w07Qn1GEZXq46z2IxQlaWnE6F/wLzsWeblnKFv1ScgPLuxWJE c+aQkIy+KLmR82Kwj2qc8Nc7a0Tg3tcZD4zXmC5AvlZHwnDGUBjlcNHnj0s7gVTrjVUk GqMhjqf4XWpUZQbPRuAOe+e7awyhzr4T1l2lmVkhYjZ5ziYRJkz8SiEw06Nawb9GgREv yR6q00Pdfg8mdy7W85ztRmcwwc2FQCVy+N5OtT/LCj87Kd2H2rkqGQcxoIQqfJEvUvY5 faGQ== X-Gm-Message-State: ANoB5pl5OnOU5SBYdFGPqxvXcv8f2Sm+ww6QrQCcLBo+9VGyAEoS6WAB /06tpYqT6IEKnnIh836N5KA= X-Google-Smtp-Source: AA0mqf49tA4SjW+c9v+ZPANNpSt3hAOSmxdE1wnrY1bTQpzl1AfVRen+cXfMULDKnCksqVNQDiWO7g== X-Received: by 2002:a17:902:e887:b0:189:1fcf:6ceb with SMTP id w7-20020a170902e88700b001891fcf6cebmr31991710plg.45.1669652119499; Mon, 28 Nov 2022 08:15:19 -0800 (PST) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id 17-20020a170902c11100b00180033438a0sm9066965pli.106.2022.11.28.08.15.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Nov 2022 08:15:18 -0800 (PST) Message-ID: <85ca8410-376b-5de7-0cfd-c213d8ab0cbd@gmail.com> Date: Mon, 28 Nov 2022 09:15:17 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [PING][PATCH] RISC-V: Avoid redundant sign-extension for SImode SGE, SGEU, SLE, SLEU Content-Language: en-US To: "Maciej W. Rozycki" Cc: Kito Cheng , GCC Patches , Andrew Waterman References: <904539a8-00ca-851c-b893-d6684d58df73@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=-1.1 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP 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 11/28/22 08:38, Maciej W. Rozycki wrote: > On Mon, 28 Nov 2022, Jeff Law wrote: > >>>>> LGTM, but with a nit, I don't get set.w but get an andi like below, so >>>>> maybe we should also scan-assembler-not andi? feel free to commit that >>>>> directly with that fix >>>>> >>>>> ```asm >>>>> sleu: >>>>> sgtu a0,a0,a1 # 9 [c=4 l=4] *sgtu_disi >>>>> xori a0,a0,1 # 10 [c=4 l=4] *xorsi3_internal/1 >>>>> andi a0,a0,1 # 16 [c=4 l=4] anddi3/1 >>>>> ret # 25 [c=0 l=4] simple_return >>>>> ``` >>>> Interesting. I can do that, but can you please share the compilation >>>> options, given or defaulted (from `--with...' configuration options), this >>>> happens with? >>> I have noticed it went nowhere. Can you please check what compilation >>> options lead to this discrepancy so that we can have the fix included in >>> GCC 13? I'd like to understand what's going on here. >> FWIW, I don't see the redundant sign extension with this testcase at -O2 on >> the trunk.  Is it possible the patch has been made redundant over the last few >> months? > Maybe at -O2, but the test cases continue to fail in my configuration for > other optimisation levels: > > FAIL: gcc.target/riscv/sge.c -O1 scan-assembler-not sext\\.w > FAIL: gcc.target/riscv/sge.c -Og -g scan-assembler-not sext\\.w > FAIL: gcc.target/riscv/sgeu.c -O1 scan-assembler-not sext\\.w > FAIL: gcc.target/riscv/sgeu.c -Og -g scan-assembler-not sext\\.w > FAIL: gcc.target/riscv/sle.c -O1 scan-assembler-not sext\\.w > FAIL: gcc.target/riscv/sle.c -Og -g scan-assembler-not sext\\.w > FAIL: gcc.target/riscv/sleu.c -O1 scan-assembler-not sext\\.w > FAIL: gcc.target/riscv/sleu.c -Og -g scan-assembler-not sext\\.w I may have been running an rv32 toolchain...  So I'll start over and ensure that I'm running rv64 :-) With the trunk, I get code like Kito (AND with 0x1 mask) The key difference is Roger's patch: commit c23a9c87cc62bd177fd0d4db6ad34b34e1b9a31f Author: Roger Sayle Date:   Wed Aug 3 08:55:35 2022 +0100     Some additional zero-extension related optimizations in simplify-rtx.     This patch implements some additional zero-extension and sign-extension     related optimizations in simplify-rtx.cc.  The original motivation comes     from PR rtl-optimization/71775, where in comment #2 Andrew Pinksi sees:     Failed to match this instruction:     (set (reg:DI 88 [ _1 ])         (sign_extend:DI (subreg:SI (ctz:DI (reg/v:DI 86 [ x ])) 0))) [ ... ] With that patch the sign extension is removed and instead we generate the AND with 0x1. Old, from combine dump:   Successfully matched this instruction:   (set (reg/i:DI 10 a0) !     (sign_extend:DI (reg:SI 78))) New, from combine dump:   (set (reg/i:DI 10 a0) !     (and:DI (subreg:DI (reg:SI 78) 0) !         (const_int 1 [0x1]))) Note the date on Roger's patch, roughly the same time as yours. I suspect Kito had tested the truck with Roger's patch. Your patch is probably still useful.  I think Kito's only concern was to make sure we don't have the ANDI instruction in addition to not having the SEXT instruction.  So still approved for trunk, just update the testcases to make sure we don't have the ANDI too. jeff