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

[Hal Finkel via Phabricator via llvm-commits]

hfinkel added a comment.

In https://reviews.llvm.org/D41096#954727, @craig.topper wrote:

> 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.


We need to update Clang and getHostCPUFeatures anyway, but I think we can arrange the features so that we don't need to update the lit tests or break JIT users. If we need +avx512f to imply +avx512-wide-vectors, and we need +avx512vl (and other avx512 features) to imply +avx512f, and we don't want those names to change (so that we don't need to update lit tests and don't break JITs, etc.), then we'll need to split all of the features. So +avx512f functionally becomes +avx512f-core and +avx512f becomes a TableGen definition implying +avx512f-core and +avx512-wide-vectors. +avx512vl becomes a TableGen definition implying +avx512vl-core and +avx512-wide-vectors, and so on. We'll double the number of feature definitions in TableGen, but leave the actual number of subtarget members the same (plus one for HasAVX512WideVectors).


https://reviews.llvm.org/D41096