[Mesa-dev] [PATCH 2/2] gallivm: permit use of avx512 instructions on llvm-3.9+

Roland Scheidegger sroland at vmware.com
Fri Nov 4 03:40:46 UTC 2016


Am 04.11.2016 um 04:24 schrieb Rowley, Timothy O:
> 
>> On Nov 3, 2016, at 7:09 PM, Roland Scheidegger <sroland at vmware.com> wrote:
>>
>> I'm a bit worried by this.
>> We've had some (a lot actually) unpleasant surprises in the past with
>> llvm choosing to use instruction sets not appropriate for a given cpu...
>> Hence only setting flags we checked ourselves being available, and
>> disabling everything else. Not sure if this actually still works though
>> given we set the host cpu name…
> 
> I’ve experienced the fragility of just using the host cpu name in llvm, though I thought it usually fails in the conservative direction.  Doing a little googling I see there was recently a bit of a hiccup with skylake accidentally using evex encoding.
Well that's not the first one for sure.
Based on experience, there is roughly a 100% probability (I think maybe
slightly more than that even...) that we'll hit some bug again with some
future llvm version and some future cpus... I don't trust llvm one bit
there, sorry. (Albeit we've lost there in any case, since we can't
disable features we don't know about.)


>> We do not want llvm to use evex encoded instructions (with any bit
>> width) for llvmpipe at this point on "ordinary" x86 cpus (I'm
>> specifically thinking about normal, albeit future, xeons, like
>> skylake-ep), as that would be a completely untested path (albeit, as I
>> said, I'm not even sure the current code actually really prevents
>> that...) - well I suppose you tested it with KNL, which is good to know.
>> Enabling it on KNL is fair enough I suppose, but I'm not sure if you can
>> detect such cpus easily based on feature, do they lack something which
>> the normal cpus have? I guess though since it's otherwise only mattering
>> for not yet released cpus we could still fix it up later if necessary…
> 
> KNL could be detected by looking for the processor family, but that would prevent future avx512 processors from just working.  What would you think of replacing the manually maintained list of mattr overrides for x86 with some code that just uses what getHostCPUFeatures (based on cpuid) returns?  Something like this:
> 
> #if defined(PIPE_ARCH_X86) || defined(PIPE_ARCH_X86_64)
>    llvm::StringMap<bool> features;
>    llvm::sys::getHostCPUFeatures(features);
> 
>    for (StringMapIterator<bool> f = features.begin(); f != features.end(); ++f) {
>       MAttrs.push_back(((*f).second ? "+" : "-") + (*f).first().str());
>    }
> #endif

Doesn't sound too bad. I still don't like the idea of enabling evex
encoding if we're only going to use 256bit vectors without some real
testing, though...
But I don't really have a much better idea, if you restrict the above to
3.9+... Can always introduce some env disabling it I suppose if needed
later...

Roland



> -Tim
> 
>> Roland
>>
>> Am 03.11.2016 um 22:29 schrieb Tim Rowley:
>>> ---
>>> src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
>>> index bd4d4d3..bff2198 100644
>>> --- a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
>>> +++ b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
>>> @@ -583,6 +583,8 @@ lp_build_create_jit_compiler_for_module(LLVMExecutionEngineRef *OutJIT,
>>>       MAttrs.push_back("-fma");
>>>    }
>>>    MAttrs.push_back(util_cpu_caps.has_avx2 ? "+avx2" : "-avx2");
>>> +
>>> +#if HAVE_LLVM <= 0x0308
>>>    /* disable avx512 and all subvariants */
>>> #if HAVE_LLVM >= 0x0304
>>>    MAttrs.push_back("-avx512cd");
>>> @@ -596,6 +598,7 @@ lp_build_create_jit_compiler_for_module(LLVMExecutionEngineRef *OutJIT,
>>>    MAttrs.push_back("-avx512vl");
>>> #endif
>>> #endif
>>> +#endif
>>>
>>> #if defined(PIPE_ARCH_PPC)
>>>    MAttrs.push_back(util_cpu_caps.has_altivec ? "+altivec" : "-altivec");
>>>
>>
> 



More information about the mesa-dev mailing list