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.
Jakub
