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
signature.asc
Description: OpenPGP digital signature
