Re: [PATCH 01/10] i386: Properly encode vector registers in vector move

[Jeff Law <law@redhat.com>]

On Thu, 2020-02-27 at 06:50 -0800, H.J. Lu wrote:
> 
> How about this?  If it looks OK, I will post the whole patch set.
It's better.  I'm guessing the two cases that were previously handled with
vextract/vbroadcast aren't supposed to happen?  They're caught here IIUC:

> +  /* NB: To move xmm16-xmm31/ymm16-ymm31 registers without AVX512VL,
> +     we can only use zmm register move without memory operand.  */
> +   if (evex_reg_p
> +       && !TARGET_AVX512VL
> +       && GET_MODE_SIZE (mode) < 64)
> +     {
> +       if (memory_operand (operands[0], mode)
> +	   || memory_operand (operands[1], mode))
> +	gcc_unreachable ();
> 

If they truly can't happen, that's fine.  My worry is I don't see changes to
the operand predicates or constraints which would avoid this case.   Is it
prevented by the mode iterator on the operands?  Again, just want to make sure
I understand why the vextract/vbroadcast stuff isn't in the new code.

I'm doing a little assuming that the <ssescalarsize> bits in the old code are
mapped correctly to the 32/64 suffixes on the opcodes in the new version.

I'm also assuming that mapping of "size" in the argument to ix86_get_ssemov to
the operand modifiers g, t, and x are right.  I'm guessing the operand
modifiers weren't needed in the original because we had the actual operand and
could look at it to get the right modifier.  In the evex, but not avx512vl case
those are forced to a g modifier which seems to match the original.

Are we going to need further refinements to ix86_output_ssemov/ix86_get_ssemov?
If so, then I'd suggest the next patch be those patterns which don't require
further refinements to ix86_output_ssemov.

If no further refinements to ix86_output_ssemov/ix86_get_ssemov are required,
then I think you can just send the rest of the pattern changes in a single
unit.

jeff