_;
#elif defined(__EVEX256__):
__mm256.*__;
#else
__mm512.*__;
#endif
If we understand correctly, we'll consider the request. But since we're about
to have a vacation, follow-up replies may be a bit slower.
BRs,
Lin
-Original Message-----
From: ZiNgA BuRgA
Sent: Thursday, September 28, 2023 8:32
Thanks for the new patch!
I see that there's a new __EVEX512__ define. Will there be some
__EVEX256__ (or maybe some max EVEX width) define, so that code can
detect whether the compiler supports AVX10.1/256 without resorting to
version checks?
Another way (not saying this is better, just throwing out ideas) is to
break AVX10.1 into all the AVX-512 subsets.
So you'd have something like -mavx10.1-256-vl, -mavx10.1-512-vbmi etc.
* -mavx10.1-256 would effectively be an alias for all the 128+256-bit
subsets, and set the __AVX10_1__
Thanks for the responses!
It'd be unfortunate if AVX10 adoption is desired, yet there's no way to
compile existing 256-bit code to be compatible with it.
Relying on SDE to check the output isn't a particularly viable solution.
It looks like `-mavx512vl -mprefer-vector-width=256` is my best
Hi,
With the proposed design of these switches, how would I restrict AVX10.1
to particular AVX-512 subsets?
For example, usage of the |_mm256_rol_epi32| intrinsic should be
compatible on any AVX10/256 implementation, /as well as /any AVX-512VL
without AVX10 implementation (e.g. Skylake-X).
