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

Sanjay Patel via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Dec 13 06:51:11 PST 2017


spatel added a comment.

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

> The dependency isn't really an llvm dependency. You're absolutely right, that if it was just that it would be fixable by changing our instruction patterns. The problem here is about how the features and dependencies are defined in our instructions manuals. avx512f means "avx512 foundation", but only includes 512 bit instructions. The latter features imply the foundation is present.
>
> A user may expect that if they use "-march=skylake-avx512" that they can use 512-bit intrinsics in x86intrin.h. But at the same time we should generate good performing code for other users who specify -march=skylake-avx512 and didn't write any vector code in their source. Based on the data we've seen so far, the best way to do that is to disable 512-bit instructions.
>
> So what I'm looking for a solution that optimizes for the likely case that the user code doesn't contain 512-bit vector intrinsics and tells the legalizer to use 256-bit registers only. But if the user code does contains explicit 512-bit intrinsics, we still allow that code to compile and ideally generate what the user expected. I don't want existing 512-bit intrinsic code to suddenly stop compiling with -march=skylake-avx512.


Instead of lying to the legalizer, I'd recommend the 2nd option that was proposed (but not exactly in these terms) - create an imaginary skylake CPU variant that does what you want: it has the new instructions, but it doesn't have 512-bit flavors of anything. Let's call this hypothetical subtarget 'skylake-avx257'. In the common case where there's no explicit 512-bit instruction usage in a function, we would just translate -march=skylake=avx512 to -march=skylake-avx257. That guarantees no 512-bit ops for that function. In the rare case where there is explicit 512-bitness, we fall back to using prefer-vector-width. We can't guarantee what will happen in that case, but we do our best and hopefully it's too rare to care about.

The upside is that it's probably just a matter of time before the fake target becomes a real product anyway, so we're going to need a skylake-avx257 sooner or later. :)


https://reviews.llvm.org/D41096





More information about the llvm-commits mailing list