================
@@ -205,36 +205,34 @@ static cl::opt<bool> ForceTargetSupportsMaskedMemoryOps(
cl::desc("Assume the target supports masked memory operations (used for "
"testing)."));
-// Option prefer-predicate-over-epilogue indicates that an epilogue is
undesired,
-// that predication is preferred, and this lists all options. I.e., the
-// vectorizer will try to fold the tail-loop (epilogue) into the vector body
-// and predicate the instructions accordingly. If tail-folding fails, there are
-// different fallback strategies depending on these values:
-namespace PreferPredicateTy {
- enum Option {
- ScalarEpilogue = 0,
- PredicateElseScalarEpilogue,
- PredicateOrDontVectorize
- };
-} // namespace PreferPredicateTy
+// Option prefer-tail-folding indicates that an epilogue is undesired, that
+// tail folding is preferred, and this lists all options. I.e., the vectorizer
+// will try to fold the tail-loop (epilogue) into the vector body and the
+// instructions accordingly. If tail-folding fails, there are different
fallback
+// strategies depending on these values:
+namespace PreferTailFoldingTy {
+enum Option {
+ PreferEpilogue = 0,
----------------
david-arm wrote:
Given that `Option` lies within the namespace `TailFoldingPolicyTy` it should
also be safe to use `None` instead of `PreferEpilogue` if that's simpler? Also,
what do you think about being a bit stronger in the names, i.e.
```
namespace TailFoldingPolicyTy {
enum Option {
None = 0,
PreferFoldTail,
MustFoldTail
};
} // namespace TailFoldingPolicyTy
```
? 'Prefer' here gives a bit more flexibility in the interpretation, since we
may still not decide to create an epilogue even if we don't tail-fold, for
example we might know the trip count will always be a multiple of any chosen
VF. `MustFoldTail` implies no other style of vectorisation is permitted and if
the legality checks fail we cannot vectorise.
It also has the advantage of shortening the options. :)
https://github.com/llvm/llvm-project/pull/191803
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
