From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by sourceware.org (Postfix) with ESMTPS id D5A4D3858D37 for ; Mon, 27 Mar 2023 02:05:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D5A4D3858D37 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-x1029.google.com with SMTP id mp3-20020a17090b190300b0023fcc8ce113so10317711pjb.4 for ; Sun, 26 Mar 2023 19:05:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679882711; 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=O+lHjyfALFUlYblfNQT0SUu1lnCncSyb0650/rM9FDg=; b=LFJ4ik3KUyB+/w1XA6cX1VbG3nCozXMXOA+kiAk4ZTIwg5hFBDkGbfmT1bVe+GXEq7 RhhSWD6SLEUXuviqtBbuaoRTgtMTHEG0ZtIIsYSDkshEFWfuMxo5WrjBGnXtCtY/9Y9b i5NCs+QN450u85mnL2+QVBoSl2wjojopW3XpnsNiVX507E/fahV7tNIrD3JHhwoU1YTB afoJIMX3o/yt5LR7+73HsY8eEjV3v7C91a2Zleg3+i320KjmbJBeh2bf6nKTzyjUp+vJ t1Aof5f5/ZOKTVsxcR0JT26l8gEwKPlquOtrPdpwMIhIiObOCwASfNJgyH8PpUoltRbA 43Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679882711; 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=O+lHjyfALFUlYblfNQT0SUu1lnCncSyb0650/rM9FDg=; b=diXlRU1sfDBIN9SzV5fwa80Sy50vPKfe0VsWxGr0vZgt+htN8jJ1NYJO1x0YtSH2Un puoRBiWIdLJHjFIsQnkOa1XB0a6JQRQSyELpXjrI/5nVHlHjyM4GfZml4w8vllAAGHog YEC+oJgps8gh2TjsbrPFhOKPgbmDpwnXchnsjSKFdJmZhcrCGniGh7/ZbwxvdxE1ohsT o5MSYKyi/MchnV3gFgS1j/whAWWiMhTqe5F4fYMuU7/pdNPOvfsl+XldvdSZXY6dQM+J MqdZ7LdykteeVhvxQxZ99gUqiB7IzUu616VCWei8s5i2TKfW3sP2O9DwZeG3uXG7XPkc TPBQ== X-Gm-Message-State: AAQBX9fBH70Hu4NzBZZmSfzjkIE7+KxfJSKprik87nvmD2i81LTDMWdH Q4hF7JWjmP6CbN2iEtDiTrQ= X-Google-Smtp-Source: AKy350b5o4Sx4KiAFXRWSdCMxdFyaRc05BYCTxytszwhwHutD42+GR80OxjbhtGuQSXKHCZhIgPITg== X-Received: by 2002:a17:90b:1643:b0:23a:5f51:6ee5 with SMTP id il3-20020a17090b164300b0023a5f516ee5mr12082670pjb.12.1679882710711; Sun, 26 Mar 2023 19:05:10 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id s17-20020a17090a5d1100b0023d3845b02bsm6315305pji.45.2023.03.26.19.05.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 26 Mar 2023 19:05:10 -0700 (PDT) Message-ID: <5e748fcd-9bd0-1ee3-f556-a2bee0037128@gmail.com> Date: Sun, 26 Mar 2023 20:05:09 -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: Feng Wang , "juzhe.zhong@rivai.ai" , gcc-patches Cc: "kito.cheng" , palmer References: <5f830f90-f31a-6687-f337-e8c3c3c8bb8f@gmail.com> <2023032709324888534814@eswincomputing.com> From: Jeff Law In-Reply-To: <2023032709324888534814@eswincomputing.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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/26/23 19:32, Feng Wang wrote: > On 2023-03-26 02:18  Jeff Law wrote: >> >> >> >> 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 > Hi Jeff，Do you think my patch modification is suitable?What else needs to be improved？ I haven't looked at it in any detail. We're in stage4 right now, so it's regression bugfixes only going into the tree. Once gcc-13 branches I'll be focused on helping folks move RVV forward, submitting/refining various RISC-V patches from Ventana and reviewing other RISC-V related patches. Jeff