From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) by sourceware.org (Postfix) with ESMTPS id E15133858D1E for ; Sat, 25 Mar 2023 18:18:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E15133858D1E 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-x52d.google.com with SMTP id s19so2926467pgi.0 for ; Sat, 25 Mar 2023 11:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679768305; 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=pFxPhBqyZ7Zuw0mr1VT34o96apVYdKcFEQze/QA9vus=; b=OI1ciRVopbg1uoZNBEZ8ialBAAhKYSdacFsmwTWsiHQLxhgOd3f4YNkhp/pEe5M7kH XPJTAWhVh2LKR9oQBP7qZw/hqarhnZK47ofzkslVHAV6C6rr0Jt+px5L23pVWNVBaE3C cMjzMg/Gnbynh8ulm/K4ryyGddUB5P3HAqy1N8qzKJiHfKRBARTPCx3KKKxb2KWRSJGD IF2cIeX7Ul5bMqkfVdUWcEeEOx3TGfe6eZfmbr4TWGHMMxyAi08YFW3BzY/DH5TRP4p7 rya5Ppam0Xd6Sh4wgzizPyk8IZmXpTTav75/wc/EvDaQVPlCuTXMAD+zZT7mep2WPXiv j9hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679768305; 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=pFxPhBqyZ7Zuw0mr1VT34o96apVYdKcFEQze/QA9vus=; b=KlvrrfQjif7AQnm7UWPfRvmB70GjSoEBYv1K9OXphG6nPSQzGHVYhevfBPC4UgH68M meIw5KY/efS1XnFKrIVZBhm5almOkSf8q2CjF72h1G6F6nqsTjyGZVQaqLUK2/YgOVnp d6hLRQKstPVX08QVUaWGBXZUryp4CLB28V4a2FUTFcRJZ2c/y4FzOSkjs03n5wIC0w20 RXU/bmg/rzwwj3ZRyoOVcIst3+iktyYtfFCBPRvm1hUmiqFeCWjV/7WGs0unrm1EQvUU O6KbCFtWSmZ7gJy7+m1CAQgWXKYXt1vHrSkGpkwmrBw4gg7AGD9eX5dVRo3f/4mVSkMF ZooA== X-Gm-Message-State: AAQBX9diaHBLAkE+bYxxrEyF30APusXEiLy/tNJ4spU2rvsXfQ/VssYe QcNwEIpMk5Xhgv1hEFnYv7E= X-Google-Smtp-Source: AKy350Zo7cIYaH7c4GzLLUgnJ6k7mYozga3LngQ80ZyHj9Ge4LN6hQN0raoGpzGOAbWx0Nrf8pkX4w== X-Received: by 2002:aa7:9696:0:b0:623:848b:ce31 with SMTP id f22-20020aa79696000000b00623848bce31mr6542080pfk.27.1679768303502; Sat, 25 Mar 2023 11:18:23 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id s6-20020a63f046000000b0050bc4ca9024sm14978148pgj.65.2023.03.25.11.18.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 25 Mar 2023 11:18:23 -0700 (PDT) Message-ID: <5f830f90-f31a-6687-f337-e8c3c3c8bb8f@gmail.com> Date: Sat, 25 Mar 2023 12:18:21 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH] RISC-V: Optimize zbb ins sext.b and sext.h in rv64 Content-Language: en-US To: "juzhe.zhong@rivai.ai" , gcc-patches Cc: "kito.cheng" , palmer , wangfeng References: From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_NUMSUBJECT,NICE_REPLY_A,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: On 3/23/23 20:45, juzhe.zhong@rivai.ai wrote: > Sounds like you are looking at redundant extension problem in RISC-V port. > This is the issue I want to fix but I don't find the time to do that. > My first impression is that we need to fix redundant extension in "ree" > PASS. > I am not sure. It's actually quite a bit more complicated. Some extension elimination can and probably should be happening in gimple. In gimple you have access to type information as well as range information. So you have the opportunity to do things like rewrite the IL to use different types when it's safe to do so, or to use range information to identify when an object is already properly extended and thus eliminate the extension before we expand gimple into RTL. Once in RTL, you can use forward propagation to eliminate extensions, or at least fold them into existing operations. combine can eliminate extensions and it has the ability to track (for example) if the upper bits are copies of the sign bit, if they're known zero, etc. combine is also capable of recognizing that a load implicitly extends and using that knowledge to eliminate extensions or to discover that a pair of shifts are just zero or sign extending a value, etc etc. combine also interacts with simplify-rtx which is used by other passes, so there's a chance that work in simplify-rtx can eliminate extensions not just in combine, but in other passes as well. REE is a post-register allocation pass and kind of the last chance to eliminate extensions. So for any given redundant extension, the way to go (IMHO) is to walk through the optimizer pipeline to see where it can potentially be eliminated. In general, the earlier in the optimizer pipeline the extension can be eliminated, the better. Jeff