[Mesa-dev] [PATCH] gallivm: disable f16c when not using AVX

Jose Fonseca jfonseca at vmware.com
Mon Oct 26 02:02:50 PDT 2015

On 23/10/15 22:26, sroland at vmware.com wrote:
> From: Roland Scheidegger <sroland at vmware.com>
> f16c intrinsic can only be emitted when AVX is used. So when we disable AVX
> due to forcing 128bit vectors we must not use this intrinsic (depending on
> llvm version, this worked previously because llvm used AVX even when we didn't
> tell it to, however I've seen this fail with llvm 3.3 since
> 718249843b915decf8fccec92e466ac1a6219934 which seems to have the side effect
> of disabling avx in llvm albeit it only touches sse flags really).

Good catch.

> Possibly one day should actually try to use avx even with 128bit vectors...

In the past we needed to override util_cpu_caps.has_avx on AVX capable 
machines but where old-JIT code.  But that's no longer the case: the min 
supported LLVM version is 3.3, which supports AVX both with MCJIT and 

There, the only point of this code is to enable a developer to test SSE2 
code paths on a AVX capable machine.

There's no other reason for someone to go out of his way to override 
LP_NATIVE_VECTOR_WIDTH of 256 with 128.

So maybe it's worth to make this comment clear: the sole point is to 
enable SSE2 testing on AVX machines, and all avx flags, and flags which 
depend on avx, need to be masked out.

BTW the "For simulating less capable machines" code needs to be updated 
too (it's missing has_avx2=0).

> ---
>   src/gallium/auxiliary/gallivm/lp_bld_init.c | 1 +
>   1 file changed, 1 insertion(+)
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c b/src/gallium/auxiliary/gallivm/lp_bld_init.c
> index 017d075..e6eede8 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_init.c
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_init.c
> @@ -427,6 +427,7 @@ lp_build_init(void)
>          */
>         util_cpu_caps.has_avx = 0;
>         util_cpu_caps.has_avx2 = 0;
> +      util_cpu_caps.has_f16c = 0;
>      }
>   #ifdef PIPE_ARCH_PPC_64

Reviewed-by: Jose Fonseca <jfonseca at vmware.com>


More information about the mesa-dev mailing list