on 2022/4/11 11:42 PM, Segher Boessenkool wrote:
> Hi!
> 
> On Mon, Apr 11, 2022 at 04:29:40PM +0800, Kewen.Lin wrote:
>> on 2022/4/9 1:31 AM, Segher Boessenkool wrote:
>>> On Fri, Apr 08, 2022 at 10:09:44AM +0800, Kewen.Lin wrote:
>>> For me it fails during combine: the unspec suddenly doesn't recog
>>> anymore.  That might be that "d" thing yes, that is problematical.
>>>
>>
>> I must miss something, I found in combine pass we still have the
>> the insn_code unpacktf_nodm (recog-ed).
> 
> That is recognised many passes earlier though.  When combine runs it
> will ICE because recog failed (for powerpc64-linux anyway, everything
> default, no -mcpu= etc.).
> 

OK, I guess that's why I didn't meet this ICE as I specified -mcpu=
for testing all the time.

>>> Or, try this patch?
>>>
>>> ===
>>> diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
>>> index fdfbc6566a5c..f05b8358ba0a 100644
>>> --- a/gcc/config/rs6000/rs6000.md
>>> +++ b/gcc/config/rs6000/rs6000.md
>>> @@ -14580,10 +14580,10 @@ (define_insn_and_split "unpack<mode>_dm"
>>>    [(set_attr "type" "fp,fpstore,mtvsr,mfvsr,store")])
>>>  
>>>  (define_insn_and_split "unpack<mode>_nodm"
>>> -  [(set (match_operand:<FP128_64> 0 "nonimmediate_operand" "=d,m")
>>> +  [(set (match_operand:<FP128_64> 0 "nonimmediate_operand" "=d,m,m")
>>>         (unspec:<FP128_64>
>>> -        [(match_operand:FMOVE128 1 "register_operand" "d,d")
>>> -         (match_operand:QI 2 "const_0_to_1_operand" "i,i")]
>>> +        [(match_operand:FMOVE128 1 "register_operand" "d,d,r")
>>> +         (match_operand:QI 2 "const_0_to_1_operand" "i,i,i")]
>>>          UNSPEC_UNPACK_128BIT))]
>>>    "(!TARGET_POWERPC64 || !TARGET_DIRECT_MOVE) && FLOAT128_2REG_P 
>>> (<MODE>mode)"
>>>    "#"
>>> @@ -14600,7 +14600,7 @@ (define_insn_and_split "unpack<mode>_nodm"
>>>  
>>>    operands[3] = gen_rtx_REG (<FP128_64>mode, fp_regno);
>>>  }
>>> -  [(set_attr "type" "fp,fpstore")])
>>> +  [(set_attr "type" "fp,fpstore,store")])
>>>  
>>>  (define_insn_and_split "pack<mode>"
>>>    [(set (match_operand:FMOVE128 0 "register_operand" "=&d")
>>> ===
>>>
>>>
>>
>> Nice, I confirmed this makes ICE gone, I've filed one new PR
>> PR105213 for GCC13 further tracking by associating this patch there.
> 
> Cool, I'll commit it later today then (after a final regstrap).  The
> _nodm pattern just missed the alternative for no FP regs (the _dm
> pattern has it, so just an oversight).
> 

Thanks!  So it can be counted as a regression fix instead of tiny
feature work?  Maybe we also need bif documentation change, and
gcc12 changes html update (as bif behavior changes), or it's
too small so no?

BR,
Kewen

Reply via email to