From: 钟居哲 <juzhe.zhong@rivai.ai>
To: "Jeff Law" <jeffreyalaw@gmail.com>,
gcc-patches <gcc-patches@gcc.gnu.org>
Cc: kito.cheng <kito.cheng@gmail.com>,
kito.cheng <kito.cheng@sifive.com>, palmer <palmer@dabbelt.com>,
palmer <palmer@rivosinc.com>, rdapp.gcc <rdapp.gcc@gmail.com>
Subject: Re: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering
Date: Thu, 29 Jun 2023 06:00:55 +0800 [thread overview]
Message-ID: <70EE22A0D10CD0D8+2023062906005450585022@rivai.ai> (raw)
In-Reply-To: <c5bce591-6702-7e6b-c5eb-8e62b9a3c9ef@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3455 bytes --]
You can see here:
https://godbolt.org/z/d78646hWb
The first case can't genreate vfwmul.vv but second case succeed.
Failed to match this instruction:
(set (reg:VNx2DF 150 [ vect__11.50 ])
(if_then_else:VNx2DF (unspec:VNx2BI [
(const_vector:VNx2BI repeat [
(const_int 1 [0x1])
])
(reg:DI 153)
(const_int 2 [0x2]) repeated x2
(const_int 1 [0x1])
(const_int 7 [0x7])
(reg:SI 66 vl)
(reg:SI 67 vtype)
(reg:SI 69 N/A)
] UNSPEC_VPREDICATE)
(mult:VNx2DF (float_extend:VNx2DF (reg:VNx2SF 149 [ vect__5.45 ]))
(reg:VNx2DF 148 [ vect__8.49 ]))
(unspec:VNx2DF [
(reg:SI 0 zero)
] UNSPEC_VUNDEF)))
This patch is adding this combine pattern.
juzhe.zhong@rivai.ai
From: Jeff Law
Date: 2023-06-29 00:24
To: Juzhe-Zhong; gcc-patches
CC: kito.cheng; kito.cheng; palmer; palmer; rdapp.gcc
Subject: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering
On 6/27/23 22:15, Juzhe-Zhong wrote:
> Consider the following complicate case:
> #define TEST_TYPE(TYPE1, TYPE2) \
> __attribute__ ((noipa)) void vwadd_##TYPE1_##TYPE2 ( \
> TYPE1 *__restrict dst, TYPE1 *__restrict dst2, TYPE1 *__restrict dst3, \
> TYPE1 *__restrict dst4, TYPE2 *__restrict a, TYPE2 *__restrict b, \
> TYPE2 *__restrict a2, TYPE2 *__restrict b2, int n) \
> { \
> for (int i = 0; i < n; i++) \
> { \
> dst[i] = (TYPE1) a[i] * (TYPE1) b[i]; \
> dst2[i] = (TYPE1) a2[i] * (TYPE1) b[i]; \
> dst3[i] = (TYPE1) a2[i] * (TYPE1) a[i]; \
> dst4[i] = (TYPE1) a[i] * (TYPE1) b2[i]; \
> } \
> }
>
> TEST_TYPE (double, float)
>
> Such complicate situation, Combine PASS can not combine extension of both operands on the fly.
> So the combine PASS will first try to combine one of the combine extension, and then combine
> the other. The combine flow is as follows:
>
> Original IR:
> (set (reg 0) (float_extend: (reg 1))
> (set (reg 3) (float_extend: (reg 2))
> (set (reg 4) (mult: (reg 0) (reg 3))
>
> First step of combine:
> (set (reg 3) (float_extend: (reg 2))
> (set (reg 4) (mult: (float_extend: (reg 1) (reg 3))
>
> Second step of combine:
> (set (reg 4) (mult: (float_extend: (reg 1) (float_extend: (reg 2))
>
> So, to enhance the combine optimization, we add a "pseudo vwfmul.wv" RTL pattern in autovec-opt.md
> which is (set (reg 0) (mult (float_extend (reg 1) (reg 2)))).
Hmm, something doesn't make sense here. Combine knows how to do a 3->1
combination. I would expect to see the first step fail (substituting
just one operand), then a later step try to combine all three
instructions, substituting the extension for both input operands.
Can you pass along the .combine dump from the failing case?
Jeff
next prev parent reply other threads:[~2023-06-28 22:01 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-28 4:15 Juzhe-Zhong
2023-06-28 16:24 ` Jeff Law
2023-06-28 22:00 ` 钟居哲 [this message]
2023-06-29 22:59 ` Jeff Law
2023-06-29 23:02 ` 钟居哲
2023-06-29 23:04 ` 钟居哲
2023-06-29 23:39 ` Jeff Law
2023-06-30 10:14 ` Robin Dapp
2023-06-30 22:35 ` Jeff Law
2023-07-01 11:45 ` Robin Dapp
[not found] ` <8D5801744511A6AD+6077E043-F267-4BC0-90B8-B2FCDCA10089@rivai.ai>
2023-07-03 7:49 ` Robin Dapp
2023-07-03 8:42 ` juzhe.zhong
2023-07-03 8:44 ` Robin Dapp
2023-07-03 8:45 ` juzhe.zhong
2023-07-03 8:49 ` Robin Dapp
2023-07-03 8:51 ` juzhe.zhong
2023-07-07 21:11 ` Jeff Law
2023-07-07 23:05 ` 钟居哲
2023-06-29 23:41 ` Jeff Law
[not found] ` <99D6E636A491D16D+F0E92F80-33DF-4109-912E-F9CAAD6F07B5@rivai.ai>
2023-06-29 23:48 ` Jeff Law
2023-06-30 0:44 ` juzhe.zhong
[not found] ` <2023062906005450585022@rivai.ai>
2023-06-28 22:59 ` 钟居哲
[not found] <tencent_69C89FF51CBB719C3976951FC2D71133E608@qq.com>
2023-07-03 9:32 ` Lehua Ding
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=70EE22A0D10CD0D8+2023062906005450585022@rivai.ai \
--to=juzhe.zhong@rivai.ai \
--cc=gcc-patches@gcc.gnu.org \
--cc=jeffreyalaw@gmail.com \
--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).