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 <jeffreya...@gmail.com>
Sent: Monday, March 4, 2024 6:47 AM
To: Robin Dapp <rdapp....@gmail.com>; Li, Pan2 <pan2...@intel.com>;
gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; richard.guent...@gmail.com;
Wang, Yanzhang <yanzhang.w...@intel.com>; Liu, Hongtao <hongtao....@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
