From: "Li, Pan2" <pan2.li@intel.com>
To: Jeff Law <jeffreyalaw@gmail.com>,
Robin Dapp <rdapp.gcc@gmail.com>,
"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Cc: "juzhe.zhong@rivai.ai" <juzhe.zhong@rivai.ai>,
"kito.cheng@gmail.com" <kito.cheng@gmail.com>,
"richard.guenther@gmail.com" <richard.guenther@gmail.com>,
"Wang, Yanzhang" <yanzhang.wang@intel.com>,
"Liu, Hongtao" <hongtao.liu@intel.com>
Subject: RE: [PATCH v2] DSE: Bugfix ICE after allow vector type in get_stored_val
Date: Tue, 5 Mar 2024 06:22:34 +0000 [thread overview]
Message-ID: <MW5PR11MB590839DB9D67260340FF17A9A9222@MW5PR11MB5908.namprd11.prod.outlook.com> (raw)
In-Reply-To: <2767ff68-98c8-47b6-ac3a-b3f47ba98afa@gmail.com>
Thanks Jeff for comments.
> But in the case of a vector modes, we can usually reinterpret the
> underlying bits in whatever mode we want and do any of the usual
> operations on those bits.
Yes, I think that is why we can allow vector mode in get_stored_val if my understanding is correct.
And then the different modes will return by gen_low_part. Unfortunately, there are some modes
(less than a vector bit size like V2SF, V2QI for vlen=128) are considered as invalid by validate_subreg,
and return NULL_RTX result in the final ICE.
Thus, consider stage 4 I wonder if this is a acceptable fix, aka find some where to filter-out the invalid
modes before goes to gen_low_part.
Pan
-----Original Message-----
From: Jeff Law <jeffreyalaw@gmail.com>
Sent: Monday, March 4, 2024 6:47 AM
To: Robin Dapp <rdapp.gcc@gmail.com>; Li, Pan2 <pan2.li@intel.com>; gcc-patches@gcc.gnu.org
Cc: juzhe.zhong@rivai.ai; kito.cheng@gmail.com; richard.guenther@gmail.com; Wang, Yanzhang <yanzhang.wang@intel.com>; Liu, Hongtao <hongtao.liu@intel.com>
Subject: Re: [PATCH v2] DSE: Bugfix ICE after allow vector type in get_stored_val
On 2/29/24 06:28, Robin Dapp wrote:
> On 2/29/24 02:38, Li, Pan2 wrote:
>>> So it's going to check if V2SF can be tied to DI and V4QI with SI. I
>>> suspect those are going to fail for RISC-V as those aren't tieable.
>>
>> Yes, you are right. Different REG_CLASS are not allowed to be tieable in RISC-V.
>>
>> static bool
>> riscv_modes_tieable_p (machine_mode mode1, machine_mode mode2)
>> {
>> /* We don't allow different REG_CLASS modes tieable since it
>> will cause ICE in register allocation (RA).
>> E.g. V2SI and DI are not tieable. */
>> if (riscv_v_ext_mode_p (mode1) != riscv_v_ext_mode_p (mode2))
>> return false;
>> return (mode1 == mode2
>> || !(GET_MODE_CLASS (mode1) == MODE_FLOAT
>> && GET_MODE_CLASS (mode2) == MODE_FLOAT));
>> }
>
> Yes, but what we set tieable is e.g. V4QI and V2SF.
But in the case of a vector modes, we can usually reinterpret the
underlying bits in whatever mode we want and do any of the usual
operations on those bits.
In my mind that's fundamentally different than the int vs fp case. If
we have an integer value in an FP register, we can't really operate on
the value in any sensible way without first copying it over to the
integer register file and vice-versa.
Jeff
next prev parent reply other threads:[~2024-03-05 6:22 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-26 3:25 [PATCH v1] RTL: Bugfix ICE after allow vector type in DSE pan2.li
2024-02-26 3:41 ` Hongtao Liu
2024-02-26 3:42 ` Li, Pan2
2024-02-26 5:13 ` Hongtao Liu
2024-02-26 7:38 ` Richard Biener
2024-02-26 7:41 ` Li, Pan2
2024-02-26 14:22 ` [PATCH v2] DSE: Bugfix ICE after allow vector type in get_stored_val pan2.li
2024-02-27 9:47 ` Richard Biener
2024-02-27 15:02 ` Jeff Law
2024-02-28 1:40 ` Li, Pan2
2024-02-28 4:51 ` Li, Pan2
2024-02-28 17:33 ` Jeff Law
2024-02-29 1:38 ` Li, Pan2
2024-02-29 13:28 ` Robin Dapp
2024-03-02 1:04 ` Li, Pan2
2024-03-03 22:46 ` Jeff Law
2024-03-05 6:22 ` Li, Pan2 [this message]
2024-03-12 2:08 ` Li, Pan2
2024-03-22 1:15 ` Li, Pan2
2024-03-22 18:53 ` Jeff Law
2024-03-23 5:45 ` Li, Pan2
2024-04-06 12:02 ` Li, Pan2
2024-04-18 1:46 ` Li, Pan2
2024-04-28 12:10 ` Li, Pan2
2024-04-29 15:20 ` Jeff Law
2024-04-30 1:02 ` Li, Pan2
2024-04-30 7:17 ` [PATCH v3] DSE: Fix " pan2.li
2024-04-30 11:35 ` Li, Pan2
2024-05-03 1:57 ` Li, Pan2
2024-05-03 1:51 ` [PATCH v4] " pan2.li
2024-05-16 4:06 ` Li, Pan2
2024-05-19 16:23 ` Jeff Law
2024-05-20 1:08 ` Li, Pan2
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=MW5PR11MB590839DB9D67260340FF17A9A9222@MW5PR11MB5908.namprd11.prod.outlook.com \
--to=pan2.li@intel.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=hongtao.liu@intel.com \
--cc=jeffreyalaw@gmail.com \
--cc=juzhe.zhong@rivai.ai \
--cc=kito.cheng@gmail.com \
--cc=rdapp.gcc@gmail.com \
--cc=richard.guenther@gmail.com \
--cc=yanzhang.wang@intel.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).