[PATCH] D42724: [X86] Don't make 512-bit vectors legal when preferred vector width is 256 bits and 512 bits aren't required
Craig Topper via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Feb 8 11:35:05 PST 2018
craig.topper added a comment.
For intrinsics, this patch relies on a function attribute "required-vector-width" that is not created anywhere today. We're trusting the accuracy of the attribute when it is is present and if its not present we'll assume 512-bit vectors should be allowed. I plan to add support to clang to set this attribute to 512 when any AVX512 intrinsics are used and to a smaller value if only narrower vectors are used. That will prevent the legalizer from disabling 512-bit support when it is needed. Similar will need to be done for any function arguments passed in ZMM registers. Probably for some of the pragmas as well.
================
Comment at: lib/Target/X86/X86ISelLowering.cpp:1363
// These operations are handled on non-VLX by artificially widening in
// isel patterns.
// TODO: Custom widen in lowering on non-VLX and drop the isel patterns?
----------------
RKSimon wrote:
> What happens with these? If we've disabled 512-bit vectors what is expected to happen?
If AVX512F is enabled, we can only disable 512-bit vectors if VLX is also enabled. So KNL will always allow 512-bit vectors. It's not clear how much we could do on KNL without 512-bit vectors. We'd probably have to just fall all the way back to AVX2. The only AVX512 instructions that would work without 512-bit vectors would be things like KOR/KAND/KXOR on mask registers, but you wouldn't be able to use masks in any instructions.
================
Comment at: lib/Target/X86/X86Subtarget.h:636
bool canExtendTo512DQ() const {
return hasAVX512() && (!hasVLX() || getPreferVectorWidth() >= 512);
}
----------------
canExtendTo512DQ checks !VLX to always allow widening on KNL CPUs.
https://reviews.llvm.org/D42724
More information about the llvm-commits
mailing list