[PATCH] [i386] Fix ICE of insn does not satisfy its constraints.

Liu, Hongtao hongtao.liu@intel.com
Fri Jun 4 01:03:58 GMT 2021

>-----Original Message-----
>From: Jakub Jelinek <jakub@redhat.com>
>Sent: Thursday, June 3, 2021 9:49 PM
>To: Liu, Hongtao <hongtao.liu@intel.com>
>Cc: gcc-patches@gcc.gnu.org
>Subject: Re: [PATCH] [i386] Fix ICE of insn does not satisfy its constraints.
>On Thu, Jun 03, 2021 at 05:07:26PM +0800, liuhongt via Gcc-patches wrote:
>> @@ -18163,10 +18163,10 @@ (define_expand "<insn>v16qiv16si2"
>>    "TARGET_AVX512F")
>>  (define_insn "avx2_<code>v8qiv8si2<mask_name>"
>> -  [(set (match_operand:V8SI 0 "register_operand" "=v")
>> +  [(set (match_operand:V8SI 0 "register_operand" "=Yv")
>>  	(any_extend:V8SI
>>  	  (vec_select:V8QI
>> -	    (match_operand:V16QI 1 "register_operand" "v")
>> +	    (match_operand:V16QI 1 "register_operand" "Yv")
>>  	    (parallel [(const_int 0) (const_int 1)
>>  		       (const_int 2) (const_int 3)
>>  		       (const_int 4) (const_int 5)
>Why do you need this change (and similarly other v -> Yv changes)?
>I mean, ix86_hard_regno_mode_ok for TARGET_AVX512F
>&& !TARGET_AVX512VL should return false for the 16-byte and 32-byte vector
>The reason to use Yv is typically where the match_operand has 64-byte vector
>mode or scalar mode, yet it needs an AVX512VL instruction.
>The changes to use Yw look ok, that is for the cases where the insn requires
>both AVX512VL and AVX512BW, while ix86_hard_regno_mode_ok ensures
>the xmm16+ regs won't be used for the 16/32-byte vectors when AVX512VL is
>not on, it doesn't ensure that AVX512BW will be enabled.
Thanks for the review.
Yes, you're right, AVX512VL parts are already guaranteed by ix86_hard_regno_mode_ok.

Here is updated patch.
>	Jakub

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-i386-Fix-ICE-of-insn-does-not-satisfy-its-constraint_v2.patch
Type: application/octet-stream
Size: 8405 bytes
Desc: 0001-i386-Fix-ICE-of-insn-does-not-satisfy-its-constraint_v2.patch
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20210604/9cc99310/attachment-0001.obj>

More information about the Gcc-patches mailing list