From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) by sourceware.org (Postfix) with ESMTPS id 10B493858D35 for ; Thu, 3 Aug 2023 14:56:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 10B493858D35 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sifive.com Received: by mail-pg1-x52e.google.com with SMTP id 41be03b00d2f7-56433b18551so580185a12.3 for ; Thu, 03 Aug 2023 07:56:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; t=1691074572; x=1691679372; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=KtbDIq47wmLrtHkrJEZ7Ivc0BnQMx1DimDZMeLLfx5o=; b=WAY6GLDT2YlALOcdqYwf4L3k5cr4Fy4T/t3dNTchCe/V4aX5Q2FK7awPIpUoJvZ069 Io05TtljcsvtuwR61CtKSqwabC6TNBH7NYrzlNB9QuS8z9ofDZTjt8VRe2SuHC8yBO8Z h+IrDU5c0hfGAmlDsNFI03Tt7onBIfKk2aeS1vdmcl/TLjJrkhBrWrw/FBCRXN/v/AdK 7w6H/Q2Yl+R1V3DhYP0LCTO764B34xk8v8GC7VyPU5+Kh2CXRAuWVqDWwHqFrc9Aigki X9Jd99eXvMFlMf8mkoqRo/CdJJMWJuqjTsQZf5smRbi3VfP/dkjYa1ViJqYPey2jM8hU +f8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691074572; x=1691679372; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KtbDIq47wmLrtHkrJEZ7Ivc0BnQMx1DimDZMeLLfx5o=; b=WgdITOIG/SG1t6F646vnA3gWOULhdlsJrX+VIu8DuptaPAzs20MB3odnvBK8O+kJz3 hA0g69BAdfd7tfGTpP7wMFFQ4Lmt7Bb2BrfgvkqodfgME7LCzGWtKCFGmnZplughuZHM +lL+SaIL7TWZqxyuwHRAlXmga9s7PDSL98/jsigqbQU85VU4HNpRWqDTsPJ248yqjLDR 2SMqaekC6/0L4PwOLwXDJM/waqDhLWIq3+ZSYozBRF5cbkFU5CTB4Ad4KVFLAceLUarU eeYSaX9Ma6j+VIjW/10jaRXHN2gVTxnRw97b8FgaanhuCtwIyF1kmjluO5LkrVlFs1wj XNYw== X-Gm-Message-State: ABy/qLZqjtNn9PwusfZPhDU3+zLXWu92QpUifW29Rqc/gze85dvxFG8M NgjKSWAYYcyZZvRanmZAwyzCnsKiwupiq8qqBTzuEQ== X-Google-Smtp-Source: APBJJlHrlyl3skLi6MSEAa5xrApl4Lk4gl/ALBsCD1tcoBJKuo6ZuSb/iqdjhHhsErICjJ0grRxb09MRf8VRp/dXwt8= X-Received: by 2002:a17:90a:fc8c:b0:263:f5fa:cf1b with SMTP id ci12-20020a17090afc8c00b00263f5facf1bmr15409444pjb.30.1691074571993; Thu, 03 Aug 2023 07:56:11 -0700 (PDT) MIME-Version: 1.0 References: <112f5c53-4809-b71d-2296-dfaebde733cb@gmail.com> In-Reply-To: From: Kito Cheng Date: Thu, 3 Aug 2023 22:56:01 +0800 Message-ID: Subject: Re: [PATCH 3/5] [RISC-V] Generate Zicond instruction for select pattern with condition eq or neq to 0 To: Jeff Law Cc: Robin Dapp , gcc-patches , "kito.cheng" , zengxiao , =?UTF-8?B?6ZKf5bGF5ZOy?= Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_NUMSUBJECT,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: > >> 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. OK, so I'm going to retreat from there, I've another lld issue that needs to be fixed before the LLVM 17 release :) > > > > > 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. Yeah, it should be cheap, but might be expensive on some HW implementation, anyway our cost model really needs to be tidy up at some point...:P > jeff