>-----Original Message----- >From: Jakub Jelinek <ja...@redhat.com> >Sent: Thursday, June 3, 2021 9:49 PM >To: Liu, Hongtao <hongtao....@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 >modes. > >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
0001-i386-Fix-ICE-of-insn-does-not-satisfy-its-constraint_v2.patch
Description: 0001-i386-Fix-ICE-of-insn-does-not-satisfy-its-constraint_v2.patch
