phoebewang wrote:
> I also think we need a policy regarding what test coverage we need for
> various avx512 features (when should we assume avx512vl etc.)
Considering the new evolution in AVX10, we should switch testing model from
`avx512xxx ± avx512vl` to `avx512xxx + avx512vl ±
evex512`.
I also imagine we can turn any avx512 feature, e.g., `bool hasBWI() {return
HasBWI;}` into `bool hasBWI() {return HasBWI & HasVLX;}`, then remove all
`hasVLX` checks in the code, e.g., `Subtarget.hasVLX() && Subtarget.hasBWI()`
to `Subtarget.hasBWI()`.
> I think if we have an approach that allows people to emulate a very basic
> KNL/KNM implementation with the equivalent of "-march=x86-64-v3 -mavx512f
> -mavx512cd" then that would be sufficient.
This will require compiler and tests continue to handle cases avx512f/avx512cd
without avx512vl. It conflicts with my expectation for `hasVLX` clean up. But
maybe we can preserve these handling for few features for a short period.
> We should keep asm handling for avx512er/avx512pf/etc but no need for
> attributes/intrinsics handling for them - if somebody needs to write assembly
> for them we shouldn't prevent it.
+1
https://github.com/llvm/llvm-project/pull/75580
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
