On 14/11/2018 14:17, Jan Beulich wrote:
>>>>> +static const struct test avx512f_all[] = {
>>>>> + INSN_SFP(mov, 0f, 10),
>>>>> + INSN_SFP(mov, 0f, 11),
>>>>> + INSN_PFP_NB(mova, 0f, 28),
>>>>> + INSN_PFP_NB(mova, 0f, 29),
>>>>> + INSN(movdqa32, 66, 0f, 6f, vl, d_nb, vl),
>>>>> + INSN(movdqa32, 66, 0f, 7f, vl, d_nb, vl),
>>>>> + INSN(movdqa64, 66, 0f, 6f, vl, q_nb, vl),
>>>>> + INSN(movdqa64, 66, 0f, 7f, vl, q_nb, vl),
>>>>> + INSN(movdqu32, f3, 0f, 6f, vl, d_nb, vl),
>>>>> + INSN(movdqu32, f3, 0f, 7f, vl, d_nb, vl),
>>>>> + INSN(movdqu64, f3, 0f, 6f, vl, q_nb, vl),
>>>>> + INSN(movdqu64, f3, 0f, 7f, vl, q_nb, vl),
>>>>> + INSN(movntdq, 66, 0f, e7, vl, d_nb, vl),
>>>>> + INSN(movntdqa, 66, 0f38, 2a, vl, d_nb, vl),
>>>>> + INSN_PFP_NB(movnt, 0f, 2b),
>>>>> + INSN_PFP_NB(movu, 0f, 10),
>>>>> + INSN_PFP_NB(movu, 0f, 11),
>>>>> +};
>>>>> +
>>>>> +static const struct test avx512f_128[] = {
>>>>> + INSN(mov, 66, 0f, 6e, el, dq64, el),
>>>>> + INSN(mov, 66, 0f, 7e, el, dq64, el),
>>>>> + INSN(movq, f3, 0f, 7e, el, q, el),
>>>>> + INSN(movq, 66, 0f, d6, el, q, el),
>>>>> +};
>>>>> +
>>>>> +static const struct test avx512bw_all[] = {
>>>>> + INSN(movdqu8, f2, 0f, 6f, vl, b, vl),
>>>>> + INSN(movdqu8, f2, 0f, 7f, vl, b, vl),
>>>>> + INSN(movdqu16, f2, 0f, 6f, vl, w, vl),
>>>>> + INSN(movdqu16, f2, 0f, 7f, vl, w, vl),
>>>>> +};
>>>>> +
>>>>> +static const unsigned char vl_all[] = { VL_512, VL_128, VL_256 };
>>>>> +static const unsigned char vl_128[] = { VL_128 };
>>>> What are these for, and why is vl_all[]'s VL_128 out of order?
>>> The RUN() macro invocations (further down) reference one them
>>> each, to indicate what vector lengths to test. The first array
>>> entry does always get used, while subsequent entries (if any)
>>> require AVX512VL to be available. See the conditional at the top
>>> of the inner loop in test_group().
>> After re-reading the apparently relevant bits of Vol 1, 2 and 3, I'm
>> still actually none the wiser as to which AVX512 feature bits mean what.
> What feature bits are you talking about? The context above doesn't
> refer to any, at least not directly.
I was referring to the AVX512 cpuid flags.
For example, it took me until writing that comment to realise that the
VL feature bit behaved in the opposite way to how I expected it to
behave. (I.e. it allows you to encode EVEX instructions which don't
refer to %zmm register).
Having said all of this, having searched about online, I think the
Wikipedia AVX-512 page is probably the closes to what I was looking for,
so perhaps us writing our own breakdown isn't the best idea.
~Andrew
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
