Meinersbur added a comment. In D94779#2556274 <https://reviews.llvm.org/D94779#2556274>, @dmgreen wrote:
> This makes sense to me. If the user specifies the pragma then we send that > through to the vectorizer, whatever it is. As much as `vectorize_width(1) > interleave_count(4) vectorize_predicate(enable)` doesn't make a lot of sense, > it's still something that should work. And if the user asks for it, that's > what should be done. Unfortunately, it is not that simple. How vectorize metadata is emitted, how it is interpreted by the LoopVectorize pass, and when the WarnMissedTransformations pass emits a warning is non-trivial and I would not mess with it with no reason or if we generally wanted to clean this up. For instance, is implicitly enabling the vectorizer when the width is set the front-end's jobs or the LoopVectorizers? The function `hasVectorizeTransformation` in LoopUtils.h tries to abstract from that. That is, there is no 1-to-1 relationship between loop hint pragmas and loop metadata as you seem to assume. The summary motivates this as "This ensures better feedback for the user/programmer." However, the user will not see any difference since the LoopVectorize will just ignore it. Worse, the IR contains contradicting information. IMHO, it's the font-end's job to resolve semantic inconsistencies and potentially warn users about it. I don't intend to block this patch because it seems to have no consequence, but the motivation is insufficient. If the author uses the predicate in an upstream pass they should mention it. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D94779/new/ https://reviews.llvm.org/D94779 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
