From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpbgeu2.qq.com (smtpbgeu2.qq.com [18.194.254.142]) by sourceware.org (Postfix) with ESMTPS id EF0C73857C45 for ; Thu, 21 Sep 2023 09:51:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EF0C73857C45 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivai.ai Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivai.ai X-QQ-mid: bizesmtp74t1695289892tynjf9n8 Received: from [10.101.11.9] ( [113.104.214.157]) by bizesmtp.qq.com (ESMTP) with id ; Thu, 21 Sep 2023 17:51:31 +0800 (CST) X-QQ-SSF: 01400000000000C0F000000A0000000 X-QQ-FEAT: IcCSTr/hHjPaUs0KYOcxReyXAeSSI8g8bheWLv7TkbdGztwy1eE28AN0Mb7H0 0P5fUlYTAjk6nEFJiYBIgdQWpbVFonhh4BVhEvLnM9SG4rQlfmGatp7iaCDSUDl2v7k5r3d CpBW1oTBVZiIGZ+1Zd1csTMsMbBF9PK/6YQnyavcE0wba+V7h3weHlfHPBVsGTmjtj/6PM9 fNz4x/kxu/BpbvD0Nsw6WquhtoT9YIVT+LZgQ1K+GnRpzl2/r1TesRE1NoJqyJzM0sfrTj9 9KdlphHua6/K3RsaO4DebRKkey4pFf5jroKjy98wHZxZKoVQXksfqGQv+gp4Ze5f2k/exqF cUFx2tcLdq8Wcg3u5mmkQ8BY2xlupVIl8dglzcr36LKm/Zjn1qDzQpVc+eeev/JfJEUJ+jX /Ia5xX+i25M= X-QQ-GoodBg: 2 X-BIZMAIL-ID: 14743617558285814141 Message-ID: <15CE81335CC42F21+c25f29e5-4570-464a-9efb-fdcc109f525a@rivai.ai> Date: Thu, 21 Sep 2023 17:51:31 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] RISC-V: Adjusting the comments of the emit_vlmax_insn/emit_vlmax_insn_lra/emit_nonvlmax_insn functions Content-Language: en-US To: Robin Dapp , gcc-patches@gcc.gnu.org Cc: juzhe.zhong@rivai.ai, kito.cheng@gmail.com, palmer@rivosinc.com, jeffreyalaw@gmail.com References: <20230921071118.3321383-1-lehua.ding@rivai.ai> <346cc997-ca97-5cf9-d20c-e50206f6eefd@gmail.com> From: Lehua Ding In-Reply-To: <346cc997-ca97-5cf9-d20c-e50206f6eefd@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:rivai.ai:qybglogicsvrgz:qybglogicsvrgz6a-0 X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA,KAM_DMARC_STATUS,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_PASS,TXREP,T_SPF_HELO_TEMPERROR 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: Hi Robin, > I once had different comments for those but either I never pushed them > or they got buried in the process of refactoring. The explanatory > comment explaining vlmax is also in "nowhere land" below autovec_use_vlmax_p. > (it says vsetvli instead of vsetvl as well...) It would be useful > to move it to above the function comments you touch. I would like to move this comment to insn_expander::emit_insn body before set avl in another patch which add VLS avl_type. > >> +/* Emit RVV insn which vl is the number of units of the vector mode. >> + This function can only be used before LRA pass or for VLS_AVL_IMM modes. */ > > Emit an RVV insn with a vector length that equals the number of units of > the vector mode. For VLA modes this corresponds to VLMAX. > > Unless the vector length can be encoded in the vsetivl[i] instruction this > function must only be used as long as we can create pseudo registers. > This is because it will set a pseudo register to VLMAX using vsetvl and > use this as definition for the vector length. > > > Besides, we could add a const_vlmax_p () || can_create_pseudo_p assert here? > > >> +/* Like emit_vlmax_insn but can be only used after LRA pass that can't create >> + pseudo register. */ > > Like emit_vlmax_insn but must only be used when we cannot create pseudo > registers anymore. This function, however, takes a predefined vector > length from the value in VL. > >> +/* Emit RVV insn which vl is the VL argument. */ >> +emit_nonvlmax_insn (unsigned icode, unsigned insn_flags, rtx *ops, rtx vl) > > I think I renamed this to emit_len_insn or something before but Juzhe didn't > like it ;) > > How about something like: > Emit an RVV insn with a predefined vector length. Contrary to emit_vlmax_insn > the instruction's vector length is not deduced from its mode but taken from > the value in VL. Thank you very much, I used all of them. Here the V2 patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631114.html -- Best, Lehua (RiVAI) lehua.ding@rivai.ai