From: Robin Dapp <rdapp.gcc@gmail.com>
To: Juzhe-Zhong <juzhe.zhong@rivai.ai>, gcc-patches@gcc.gnu.org
Cc: rdapp.gcc@gmail.com, kito.cheng@gmail.com, kito.cheng@sifive.com,
jeffreyalaw@gmail.com
Subject: Re: [PATCH] RISC-V: Support LEN_FOLD_EXTRACT_LAST auto-vectorization
Date: Thu, 24 Aug 2023 11:13:57 +0200 [thread overview]
Message-ID: <3a311c3b-c2b9-e044-f5ed-3280f3e327eb@gmail.com> (raw)
In-Reply-To: <20230824021925.1717486-1-juzhe.zhong@rivai.ai>
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<RVV_INSN_OPERANDS_MAX> 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
next prev parent reply other threads:[~2023-08-24 9:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-24 2:19 Juzhe-Zhong
2023-08-24 9:13 ` Robin Dapp [this message]
2023-08-24 9:33 ` 钟居哲
2023-08-24 9:38 ` 钟居哲
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3a311c3b-c2b9-e044-f5ed-3280f3e327eb@gmail.com \
--to=rdapp.gcc@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jeffreyalaw@gmail.com \
--cc=juzhe.zhong@rivai.ai \
--cc=kito.cheng@gmail.com \
--cc=kito.cheng@sifive.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).