[PATCH] D41096: [X86] Initial support for prefer-vector-width function attribute

Craig Topper via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Dec 13 17:09:39 PST 2017


craig.topper added a comment.

In https://reviews.llvm.org/D41096#954723, @hfinkel wrote:

> In https://reviews.llvm.org/D41096#954711, @craig.topper wrote:
>
> > Also doesn't this mean that we have to explicitly force +avx512-wide-vectors somewhere if the user passes "-mavx512f" with no -march?
> >
> >   def FeatureAVX512WideVectors : SubtargetFeature<"avx512-wide-vectors", "HasAVX512WideVectors", "true", "Enable use of 512-bit Vector Registers", [FeatureAVX512]>;
> >
>
>
> Yes, we could do that in the frontend. Or, we can make "core" AVX512 have a different name, add that to the processor feature lists, and then have a tablegen "avx512f" feature that implies both (that way -mavx512f will still act as it does today).


Well we already have an implies relationship that +avx512vl(and other avx512 features) implies +avx512f that we need to continue working. But if you make "+avx512f" imply +avx512-wide-vectors in tablegen, you also get an opposite implication that -avx512-wide-vectors implies -avx512f which would then imply -avx512vl. That disabling everything.

We could update clang and getHostCPUFeatures, but then all our lit tests need to be updated and we break JIT users.


https://reviews.llvm.org/D41096





More information about the llvm-commits mailing list