From: Richard Sandiford <richard.sandiford@arm.com>
To: "juzhe.zhong\@rivai.ai" <juzhe.zhong@rivai.ai>
Cc: kito.cheng <kito.cheng@gmail.com>,
"Robin Dapp" <rdapp.gcc@gmail.com>,
gcc-patches <gcc-patches@gcc.gnu.org>,
Kito.cheng <kito.cheng@sifive.com>, palmer <palmer@dabbelt.com>,
palmer <palmer@rivosinc.com>,
jeffreyalaw <jeffreyalaw@gmail.com>
Subject: Re: [PATCH] RISC-V: Refactor the framework of RVV auto-vectorization
Date: Tue, 23 May 2023 13:14:56 +0100 [thread overview]
Message-ID: <mptcz2rnt1b.fsf@arm.com> (raw)
In-Reply-To: <5134B4DF7BC45283+20230523170057152641154@rivai.ai> (juzhe's message of "Tue, 23 May 2023 17:00:57 +0800")
"juzhe.zhong@rivai.ai" <juzhe.zhong@rivai.ai> writes:
> Yeah. I know.
> Like ARM does everywhere:
> (define_expand "vcond<SVE_ALL:mode><SVE_I:mode>"
> [(set (match_operand:SVE_ALL 0 "register_operand")
> (if_then_else:SVE_ALL
> (match_operator 3 "comparison_operator"
> [(match_operand:SVE_I 4 "register_operand")
> (match_operand:SVE_I 5 "nonmemory_operand")])
> (match_operand:SVE_ALL 1 "nonmemory_operand")
> (match_operand:SVE_ALL 2 "nonmemory_operand")))]
> "TARGET_SVE && <SVE_ALL:container_bits> == <SVE_I:container_bits>"
> {
> aarch64_expand_sve_vcond (<SVE_ALL:MODE>mode, <SVE_I:MODE>mode, operands);
> DONE;
> }
> )
>
> passing "operands" looks codes much cleaner.
FWIW, I think we only do that when we're reusing optab patterns.
The handling of operand 3 is forced by the definition of vcond_optab.
When there's a choice, we generally use "@" patterns instead, and
pass codes and modes to the expander.
Thanks,
Richard
prev parent reply other threads:[~2023-05-23 12:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-23 6:08 juzhe.zhong
2023-05-23 8:06 ` Robin Dapp
2023-05-23 8:25 ` juzhe.zhong
2023-05-23 8:45 ` Kito Cheng
2023-05-23 9:00 ` juzhe.zhong
2023-05-23 12:14 ` Richard Sandiford [this message]
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=mptcz2rnt1b.fsf@arm.com \
--to=richard.sandiford@arm.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 \
--cc=palmer@dabbelt.com \
--cc=palmer@rivosinc.com \
--cc=rdapp.gcc@gmail.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).