On 7/20/19 8:04 PM, Richard Henderson wrote:
> On 7/11/19 3:32 PM, Jan Bobek wrote:
>> +# VEX.LIG.F3.0F.WIG 10 /r: VMOVSS xmm1, xmm2, xmm3
>> +# VEX.LIG.F3.0F.WIG 10 /r: VMOVSS xmm1, m32
>> +# VEX.LIG.F3.0F.WIG 11 /r: VMOVSS xmm1, xmm2, xmm3
>> +# VEX.LIG.F3.0F.WIG 11 /r: VMOVSS m32, xmm1
>> +VMOVSS AVX 0001000 d \
>> +  !constraints { vex($_, m => 0x0F, l => 0, p => 0xF3); modrm($_); $_->{vex}{v} = 0 unless defined $_->{modrm}{reg2}; 1 } \
>> +  !memory { $d ? store(size => 4) : load(size => 4); }
> 
> Why the l => 0?  LIG does mean VEX.L ignored, so why not let it get randomized
> as you do for WIG?
> 
> Not wrong as is... this is the documented value for scalar operands.  But there
> is a different document markup, LZ, for required (E)VEX.L == 0.

I am aware of LIG vs. LZ. Quoting from the MOVSS manual page:

  Software should ensure VMOVSS is encoded with VEX.L=0. Encoding
  VMOVSS with VEX.L=1 may encounter unpredictable behavior across
  different processor generations.

"Unpredictable behavior" sounded a bit menacing to me, so I opted for
the conservative route. AFAICT all the scalar instructions have this
warning attached; I don't know why they differentiate between LIG and
LZ then, though. Do you think it's irrelevant?

-Jan