[PATCH] D39575: [X86] Add subtarget features prefer-avx256 and prefer-avx128 and use them to limit vector width presented by TTI

Sanjay Patel via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat Nov 4 08:51:41 PDT 2017


spatel added reviewers: echristo, hfinkel.
spatel added a comment.

In https://reviews.llvm.org/D39575#915319, @craig.topper wrote:

> In the longer term we may end up making -mprefer-avx256 be on by default for skylake-avx256 so I think a vectorizer specific command line option would prevent us from having that control.


I have to look out how the plumbing works again, but I didn't follow that reasoning. Let me explain how I see this and suggest alternatives to an x86 feature flag.

By exposing this as a clang command-line option and telling programmers to recompile their code and test perf themselves, we admit that neither the hardware nor the compiler can always dynamically or statically determine the optimum vector size, but the hardware and compiler should get this right most of the time (maybe we can even model the warm-up cost of turning on the vector unit?). Therefore, we should give them the flexibility to use this option very selectively. Ideally, it would be controlled by a function-level or loop-level pragma.

If that's the right description, then we should model this as metadata or a function attribute. Is there something from OpenMP pragmas that can be adapted? If we need the backend to know the preference, we have precedence for that situation too: see the function attribute for square root estimates.


https://reviews.llvm.org/D39575





More information about the llvm-commits mailing list