Re: [Qemu-devel] [RISU PATCH v3 18/18] x86.risu: add AVX2 instructions

[Jan Bobek <jan.bobek@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1418 bytes --]

On 7/20/19 8:46 PM, Richard Henderson wrote:
> On 7/11/19 3:33 PM, Jan Bobek wrote:
>> +# VEX.256.0F.WIG 28 /r: VMOVAPS ymm1, ymm2/m256
>> +# VEX.256.0F.WIG 29 /r: VMOVAPS ymm2/m256, ymm1
>> +VMOVAPS AVX2 0010100 d \
>> +  !constraints { vex($_, m => 0x0F, l => 256, v => 0); modrm($_); 1 } \
>> +  !memory { $d ? store(size => 32, align => 32) : load(size => 32, align => 32); }
> 
> I believe all of the floating-point 256-bit operations are actually AVX1.
> Which, I see, would annoyingly require a renaming, since that would put two
> VMOVAPS insns into the same group.

Yeah.... and it is not just VMOVAPS, obviously.

> I wonder if it's worth calling the two groups AVX128 and AVX256 and ignore the
> actual cpuid to which the insn is assigned?  Which ever way, they're still tied
> to the same --xstate value to indicate ymmh.

We could do that, but I think I like your idea below even better.

> Or could we fold the two insns together:
> 
> VMOVAPS AVX 0010100 d \
> !constraints { vex($_, m => 0x0F, v => 0); modrm($_); 1 } \
> !memory { my $len = $_->{vex}{l} / 8; \
>           $d ? store(size => $len, align => $len) \
>              : load(size => $len, align => $len); }

This is a really interesting idea. If inability to differentiate
between the two is acceptable for us, then I think this approach might
be cleaner, more concise, and remove some redundancy.

-Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]