[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]

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