From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) by sourceware.org (Postfix) with ESMTPS id 30EE53858024 for ; Thu, 3 Aug 2023 14:41:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 30EE53858024 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-io1-xd32.google.com with SMTP id ca18e2360f4ac-78625caa702so37199639f.1 for ; Thu, 03 Aug 2023 07:41:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691073709; x=1691678509; 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=hNI46b9eOfbpqdjfZ77s6zLcTmB4kTYOoK0L/dDC4aI=; b=I8qv4JDq6c4wvrkzibuuiLSGgONUiqbEPKF6uJ6vRZfivend8Goebs6iKs0qBPkLSW TwS7lu+ZCJ5fcgz4BrBzL/DhHUylAlVzDAlEAT1jLzfncNXKp70fnTwmZRSV1Gbgi2KT gswUbAZHndBBb8Ey2Ni5CIPNNUi6Kx2Vi9gs3mOfdE1hcewYYUzMd4rph/gXsZ8Ku0gr iLQsMvKLM8yurgBkea+jaK0Ra0r6klrs1PFWlbTFEs6kDkp7TFSFR66Esp42vpqMvt68 DJbvv/tYBk+pM+deTEaJPF+vo7VHPahtByZ3aRmcwlrcNsJKA2EyMTTVPi2AWANvhBmo MvZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691073709; x=1691678509; 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=hNI46b9eOfbpqdjfZ77s6zLcTmB4kTYOoK0L/dDC4aI=; b=G0W3PNMx9sipxPmfYdSvz/lnRKFT5T1kCeNI2MXwlvHOndljb5hIxj00smXUXmDjPp 1eF4QYD0PuOjrdaaZ4iKOHoxd1Og2RhUe0jF8EfTK+Sc7O3M+9NRoT3XRXXDbcwxSmTZ Fq12RIuSuHACSDFClUIlg2p6zzBNezKsCURH+Dc+0xWUY1YUl9WJeAlKK6s5pMJ0ixsR /cahAwPRwa36IxN81qU53g2HmXv3QbAJ+/swZJiWbxtvwUq/1tu+SG5NkP1qIiCWPMij 3PUDRP0g/85P8uPHK+hHJP1dbRNKJH5jTM+tKcQyME0Bt8rmtIBues9IF/2ZOPBaBhcA XJcw== X-Gm-Message-State: ABy/qLZ0YnrUNDnLbEQ3IDLPb+PMAP/Yb1Q3xr9JxhhJNDp3K5SBWlKg 3Lr8GrBN6q1RtZr4M76R8Q4= X-Google-Smtp-Source: APBJJlFR5NIrViX1E7bTUiLQkT9HcRkPOW/TN+hEeGM0S1qNKGxGhKZnr3/VzL920Drszbz+DiHJiw== X-Received: by 2002:a05:6e02:1b8a:b0:349:2c56:a474 with SMTP id h10-20020a056e021b8a00b003492c56a474mr11262041ili.30.1691073709077; Thu, 03 Aug 2023 07:41:49 -0700 (PDT) Received: from [172.31.1.103] ([172.58.35.95]) by smtp.gmail.com with ESMTPSA id o1-20020a92c041000000b003423875af1bsm24559ilf.1.2023.08.03.07.41.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Aug 2023 07:41:48 -0700 (PDT) Message-ID: Date: Thu, 3 Aug 2023 08:41:46 -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: [PATCH 3/5] [RISC-V] Generate Zicond instruction for select pattern with condition eq or neq to 0 Content-Language: en-US To: Kito Cheng Cc: Robin Dapp , gcc-patches , "kito.cheng" , zengxiao , =?UTF-8?B?6ZKf5bGF5ZOy?= References: <112f5c53-4809-b71d-2296-dfaebde733cb@gmail.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 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,T_SCC_BODY_TEXT_LINE 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 8/3/23 08:31, Kito Cheng wrote: >>> I am working on that, it seems the cost of vsetvli instruction become 0 >>> due to this change, then loop invariant motion won't hoist vsetvli longer. >> I haven't looked yet (generating baseline rvv.exp data right now). But >> before I went to bed last night I was worried that a change snuck >> through that shouldn't have (changing the toplevel INSN/SET cost >> handling -- that wasn't supposed to be in the commit). I was too tired >> to verify and correct without possibly mucking it up further. >> >> That'll be the first thing to look at. THe costing change was supposed >> only affect if-then-else constructs, not sets in general. > > > If so, I think the most simple fix is adding more checks on the set > cost - only check the SET_SRC is if-then-else? No, the simple fix is to just remove the errant part of the commit :-0 My tests aren't done, but that does seem to dramatically help. Given it wasn't supposed to go in as-is and it's causing major problems, I'll probably just rip it out even though my testing isn't done. > > Let me run the regression to see if that works - although the current > vsetvli cost is too high (4x~5x), but I think it should be fixed later > with a more complete expermantal. Exactly. I think we need to do a full audit of the costing paths. I've been slowly devising a way to do that and I'll probably give it to Raphael or Jivan once I've fleshed it out a bit more in my head. The goal is to make sure the costs are sensible and consistent across the different interfaces. A cost failure is actually a bit hard to find because all that happens is you get the wrong set of transformations -- but the code still works correctly, it's just not as efficient as it should be. It doesn't have to be perfect, but we've clearly got a problem. WRT vsetvli costing. That may ultimately be something that's uarch dependent. We're working on the assumption that vsetvlis are common in the code stream and they need to be very efficient from the hardware standpoint (think as cheap or cheaper than any simple ALU instruction). I probably can't say what we're doing, but I bet it wouldn't be a surprise to others doing a high performance V implementation. jeff