craig.topper added a comment. The attribute is supposed to tell the backend if there were any vectors used in the C source code and how big they were. A value of 0 means the code didn't contain any vectors.
The backend assumes lack of the attributes means the IR didn't come from clang and can't be trusted to have been audited. That's why the backend uses UINT32_MAX. If the attribute is present and less than 512, avx512 is enabled, and we're targeting certain CPUs with a avx512 frequency penalty, the backend type legalizer in X86 will not have 512 bit vectors as legal types. This will cause any vectors larger than 512 to be split. Such vectors were likely emitted by the loop or SLP vectorizer which isn't bound to the legal vector width. If the C source used a 512 bit vector explicitly, either via target specific intrinsic, function argument or return, or inline assembly, etc. We need to have the backend treat the type as legal. If we don't do that, splitting the type could be incorrect. It could cause an ABI break across translation units. Or cause the backend legalizer to need to split something it isn't capable of splitting like a target specific intrinsic. I admit the naming is unfortunate. I think I called the attribute min-legal-vector-width because it is the "minimum vector width the backend needs to consider legal", still subject to what subtarget features actually provide. The clang code uses Max because it is calculated by maxing a bunch of things. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D139627/new/ https://reviews.llvm.org/D139627 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
