Re: [Xen-devel] [PATCH v8 30/50] x86emul: support AVX512{F, _VBMI2} compress/expand insns

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 18.06.19 at 18:24, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 11/06/2019 11:20, Jan Beulich wrote:
>>>>> On 10.06.19 at 16:51, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> On 15/03/2019 10:56, Jan Beulich wrote:
>>>> +#if __GNUC__ > 7 /* can't check for __AVX512VBMI2__ here */
>>> Why not?
>> Because that would require passing -mavx512vbmi2 (or enabling the
>> feature via #pragma) which in turn would need gating on compiler
>> version, or else the harness couldn't be built with gcc7 at all anymore.
> 
> Is that really a problem?  We already require a
> practically-bleeding-edge binutils.

"Bleeding edge" would be 2.32 or newer. {evex} support was added in
2.29, which sort of matches up with gcc 7.

> Irrespective, are you saying that __AVX512VBMI2__ really is conditional
> on -mavx512vbmi2 being passed?

Yes. How else would you expect things to work?

> If so, what's wrong with using cc-option to gain it conditionally?

We don't want to enable all sorts of AVX- and AVX512-isms in the
compilation. Besides our inline assembly we specifically want the
compiler to only produce generic code. It was intentional after all
that for the main harness object we've never added any
-m<extension> option.

>>>> --- a/xen/tools/gen-cpuid.py
>>>> +++ b/xen/tools/gen-cpuid.py
>>>> @@ -266,10 +266,10 @@ def crunch_numbers(state):
>>>>                    AVX512BW, AVX512VL, AVX512_4VNNIW, AVX512_4FMAPS,
>>>>                    AVX512_VPOPCNTDQ],
>>>>  
>>>> -        # AVX512 extensions acting solely on vectors of bytes/words are 
>>>> made
>>>> +        # AVX512 extensions acting (solely) on vectors of bytes/words are 
>>>> made
>> Because VBMI2 doesn't act _solely_ on vectors of bytes/words.
>> There are also shift insns acting on vectors of dwords/qwords.
> 
> In which case I'd expect s/solely// here.  Putting solely in brackets
> doesn't convey any information relevant to "not really solely any more".

Well, okay.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel