From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) by sourceware.org (Postfix) with ESMTPS id 16D5F3858C53 for ; Thu, 24 Aug 2023 09:14:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 16D5F3858C53 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-ej1-x630.google.com with SMTP id a640c23a62f3a-99357737980so848112866b.2 for ; Thu, 24 Aug 2023 02:14:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692868439; x=1693473239; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:from:to :cc:subject:date:message-id:reply-to; bh=pdodbr6hCXSu01Lni5tcb/30SqTBLTYHkDgRQTbH3UQ=; b=aLzmR5lMNPJeNpVFdAg4tS93j6n2qfXvvu3F3oaa+neqGoJMH8X32e0wIG27S3WoDF VfCZWoYR6n4c9wPXNvNpLsD8/0wUC/EKCmUSlSUAKMpDK3tHjnD9vICEhwdoA+5i16Vk FvvWQFcl1KlQ1ccUVEWzzvQZQ4m9kP0jz+94dmuMUzFUcxPwuGt7/6i+sWOxI6hut1To uUnPqH10+T8Pxb62bGR3p/SPAKLk1wK2JbClfRvAG7SAR85A1h7ScPW83s9mfsHDD436 re8TJf5+44IKYY1VHV47zulDzyXfEkfSVulQqmlxrnIeqdEfmkYiIp8pu1pA8zBf870Y euQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692868439; x=1693473239; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=pdodbr6hCXSu01Lni5tcb/30SqTBLTYHkDgRQTbH3UQ=; b=fsvAM5MwhoQQLdVwxbauQ0nHPY2WgGWLg8fBSZ2WVAJWASPyxm2BEV2w07He/gYBJg bVS4qFmlMDazQ2Kns8F5hp84Wt18m4Go1l6cWp/BC5++5mj/9lHi+MP8wYA7UQBOIwVZ pjr7G4CWPoh8ECb9ysXvnaDB4VCCTy7pIyCRieLYOyHcqRzitxM0Suv2btlCeJOoMn5r D7DQCeko0as8cfHbgqqn2oAS99pl1wQfG/SuuagES5/WtdQCtq9u7LkFnB0ZoDsZcBzO tsXa7rV9rAv5Gah/CjUqu1NEC4BM3SeoNwjIns7kMM1gcol7KTfVHDhTadxno98osy1e J2Qg== X-Gm-Message-State: AOJu0YwBU5VU9o9JpQSQDwDx7rLTADAYMphlYZyBn1L6xmtdgvBdfJHc 0B/C6fTK7ENpJ+rSBammL5Y= X-Google-Smtp-Source: AGHT+IFqfW+09KI7iX/TC0CpjOpT3twWW6x92BYI2iRplVc2UrIus+bynQQH1kmiiUHrcHga7DbVAw== X-Received: by 2002:a17:906:8468:b0:9a1:f928:dddc with SMTP id hx8-20020a170906846800b009a1f928dddcmr2127513ejc.41.1692868438566; Thu, 24 Aug 2023 02:13:58 -0700 (PDT) Received: from [192.168.1.23] (ip-046-005-130-086.um12.pools.vodafone-ip.de. [46.5.130.86]) by smtp.gmail.com with ESMTPSA id b16-20020a170906151000b0099df2ddfc37sm10642715ejd.165.2023.08.24.02.13.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 24 Aug 2023 02:13:58 -0700 (PDT) Message-ID: <3a311c3b-c2b9-e044-f5ed-3280f3e327eb@gmail.com> Date: Thu, 24 Aug 2023 11:13:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 From: Robin Dapp Subject: Re: [PATCH] RISC-V: Support LEN_FOLD_EXTRACT_LAST auto-vectorization To: Juzhe-Zhong , gcc-patches@gcc.gnu.org Cc: rdapp.gcc@gmail.com, kito.cheng@gmail.com, kito.cheng@sifive.com, jeffreyalaw@gmail.com References: <20230824021925.1717486-1-juzhe.zhong@rivai.ai> Content-Language: en-US In-Reply-To: <20230824021925.1717486-1-juzhe.zhong@rivai.ai> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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: Hi Juzhe, > vcpop.m a5,v0 > beq a5,zero,.L3 > addi a5,a5,-1 > vsetvli a4,zero,e32,m1,ta,ma > vcompress.vm v2,v3,v0 > vslidedown.vx v2,v2,a5 > vmv.x.s a0,v2 > .L3: > sext.w a0,a0 Mhm, where is this sext coming from? Thought I had this covered with the autovec-opt pattern but apparently not. I'll take that, nothing related to this patch. > --- a/gcc/config/riscv/riscv-v.cc > +++ b/gcc/config/riscv/riscv-v.cc > @@ -213,7 +213,7 @@ public: > { > /* Optimize VLS-VLMAX code gen, we can use vsetivli instead of > the vsetvli to obtain the value of vlmax. */ > - poly_uint64 nunits = GET_MODE_NUNITS (m_dest_mode); > + poly_uint64 nunits = GET_MODE_NUNITS (m_mask_mode); Why is that necessary? Just for the popcount I presume? Can't we rather have a new case for a scalar destination? I find the code a bit misleading now as we check m_dest_mode and then not use it. > > +/* Emit vcpop.m instruction. */ > + > +static void > +emit_cpop_insn (unsigned icode, rtx *ops, rtx len) > +{ > + machine_mode dest_mode = GET_MODE (ops[0]); > + machine_mode mask_mode = GET_MODE (ops[1]); > + insn_expander e (RVV_CPOP, > + /* HAS_DEST_P */ true, > + /* FULLY_UNMASKED_P */ true, > + /* USE_REAL_MERGE_P */ true, > + /* HAS_AVL_P */ true, > + /* VLMAX_P */ len ? false : true, > + dest_mode, mask_mode); > + > + e.set_vl (len); > + e.emit_insn ((enum insn_code) icode, ops); > +} The use_real_merge just appeared odd to me here because there is nothing to merge. But in the end it's just to omit the vundef operand so good for now. There is an increasing number of opportunities to refactor in riscv-v.cc, though ;) The rest looks good to me. Note that my machine crashed when compiling the extract_last-14.c because it used up all my RAM. The vsetvl "refactor" phase 3 patch helped, though. We'd need to have this patch depend on the other one then. The rest looks good to me. At first I was a bit wary about the branching zero check after popcount but as we're outside of a loop anyway, that's fine. Might want to use a conditional select in the future but actually not that important. Regards Robin