Thanks Richard.

Committed with V2:
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640172.html 



juzhe.zh...@rivai.ai
 
From: Richard Sandiford
Date: 2023-12-11 20:12
To: juzhe.zhong\@rivai.ai
CC: Robin Dapp; gcc-patches
Subject: Re: [PATCH] RTL-SSA: Fix ICE on record_use of RTL_SSA for RISC-V 
VSETVL PASS
"juzhe.zh...@rivai.ai" <juzhe.zh...@rivai.ai> writes:
> Thanks Richard.
>
> It would be great if you are ok I can fix it in RTL_SSA.
> I leverage your LRA patch in RTL_SSA:
>
>   else
>     {
>       // Record the mode of the largest use.  The choice is arbitrary if
>       // the instruction (unusually) references the same register in two
>       // different but equal-sized modes.
>       gcc_checking_assert (use->insn () == insn);
>       if (HARD_REGISTER_NUM_P (regno))
>         {
>           if (!ordered_p (GET_MODE_PRECISION (use->mode ()),
>                           GET_MODE_PRECISION (mode)))
>             use->set_mode (reg_raw_mode[regno]);
>           else if (partial_subreg_p (use->mode (), mode))
>             use->set_mode (mode);
>         }
>       use->record_reference (ref, false);
>     }
>
> Is it reasonable to you ?
 
Yeah, the above is OK for trunk, thanks.
 
Richard
 
>
> Thanks.
>
>
> juzhe.zh...@rivai.ai
>  
> From: Richard Sandiford
> Date: 2023-12-11 19:45
> To: juzhe.zhong\@rivai.ai
> CC: Robin Dapp; gcc-patches
> Subject: Re: [PATCH] RTL-SSA: Fix ICE on record_use of RTL_SSA for RISC-V 
> VSETVL PASS
> "juzhe.zh...@rivai.ai" <juzhe.zh...@rivai.ai> writes:
>> I think it's reasonable refactor reduction instruction pattern work around 
>> this issue.
>>
>> Going to send a patch to apply this solution.
>>
>> So drop this patch.  Sorry for bothering Richard S.
>  
> It wasn't a bother.
>  
> On the patch: as things stand, we try to make the use_info's mode be
> at least as big as all the uses in the instruction.  So if we did
> want to handle unordered modes for hard registers, I think we would need
> to fall back on the register's natural mode instead.  I did something
> similar in LRA recently for PR112278 (6e2e0ce6795).
>  
> So if in future you would like to change RTL-SSA, a fix along those
> lines would be fine with me.
>  
> Thanks,
> Richard
>  
>>
>>
>>
>> juzhe.zh...@rivai.ai
>>  
>> From: Robin Dapp
>> Date: 2023-12-11 17:01
>> To: Juzhe-Zhong; gcc-patches
>> CC: rdapp.gcc; richard.sandiford
>> Subject: Re: [PATCH] RTL-SSA: Fix ICE on record_use of RTL_SSA for RISC-V 
>> VSETVL PASS
>>> In record_use:
>>> 
>>>       if (HARD_REGISTER_NUM_P (regno)
>>>   && partial_subreg_p (use->mode (), mode))
>>> 
>>> Assertion failed on partial_subreg_p which is:
>>> 
>>> inline bool
>>> partial_subreg_p (machine_mode outermode, machine_mode innermode)
>>> {
>>>   /* Modes involved in a subreg must be ordered.  In particular, we must
>>>      always know at compile time whether the subreg is paradoxical.  */
>>>   poly_int64 outer_prec = GET_MODE_PRECISION (outermode);
>>>   poly_int64 inner_prec = GET_MODE_PRECISION (innermode);
>>>   gcc_checking_assert (ordered_p (outer_prec, inner_prec));                 
>>>     -----> cause ICE.
>>>   return maybe_lt (outer_prec, inner_prec);
>>> }
>>> 
>>> RISC-V VSETVL PASS is an advanced lazy vsetvl insertion PASS after RA 
>>> (register allocation).
>>> 
>>> The rootcause is that we have a pattern (reduction instruction) that 
>>> includes both VLA (length-agnostic) and VLS (fixed-length) modes.
>>  
>> Maybe as additional context: The second input (which has a VLA mode here)
>> is not used entirely but just its first element.  This serves as initial
>> value for the reduction.
>>  
>> I'm not sure we'd want to model it as subreg here (endianness etc?).
>> Could we have a VLS-mode equivalent for the VLA mode that only holds
>> one element?
>>  
>> Regards
>> Robin
>>  
>>  
>  
 

Reply via email to