[PATCH] D142894: [LoopVectorize] Use overflow-check analysis to improve tail-folding.
Paul Walker via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Feb 14 09:33:58 PST 2023
paulwalker-arm added inline comments.
================
Comment at: llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:1572-1579
+ TailFoldingStyle Style = TTI.getPreferredTailFoldingStyle();
+ // If we know the runtime check will be false, it's more efficient to use
+ // the DataAndControlFlow with the runtime check, because that avoids
+ // using a cmp/sel for the modified tripcount.
+ if (Style == TailFoldingStyle::DataAndControlFlowWithoutRuntimeCheck &&
+ IVUpdateCannotOverflow)
+ return TailFoldingStyle::DataAndControlFlow;
----------------
It seems weird to ask the target for their preferred style and then immediate override it. Is there a reason not to pass `IVUpdateCannotOverflow` to `getPreferredTailFoldingStyle`?
================
Comment at: llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:3039
- TailFoldingStyle Style = Cost->getTailFoldingStyle();
+ bool IVUpdateCannotOverflow = Cost->isIndvarOverflowCheckKnownFalse(VF, UF);
+ TailFoldingStyle Style = Cost->getTailFoldingStyle(IVUpdateCannotOverflow);
----------------
Up to you but personally I think for all instances the reverse polarity `IVUpdateCanOverflow` reads better.
================
Comment at: llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:3483
+bool LoopVectorizationCostModel::isIndvarOverflowCheckKnownFalse(
+ ElementCount VF, std::optional<unsigned> UF) const {
----------------
Forgive my ignorance here but this doesn't look like a cost model question?
================
Comment at: llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:3495
+ // We know the runtime overflow check is known false iff the (max) trip-count
+ // is known and (max) trip-count + VF does not overflow in the type of the
+ // vector loop induction variable.
----------------
`num-elts-per-iteration` or `(VF * UF)`?
================
Comment at: llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:3497
+ // vector loop induction variable.
+ if (std::optional<unsigned> TC = getSmallBestKnownTC(*PSE.getSE(), TheLoop)) {
+ unsigned MaxVFElts = VF.getKnownMinValue();
----------------
david-arm wrote:
> I wonder if this is safe because `getSmallBestKnownTC` also returns a value from profiling for the expected trip count, which is more like a hint rather than a definite?
This doesn't look entirely safe. I think you really want `SE.getSmallConstantTripCount`?
================
Comment at: llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:3498
+ if (std::optional<unsigned> TC = getSmallBestKnownTC(*PSE.getSE(), TheLoop)) {
+ unsigned MaxVFElts = VF.getKnownMinValue();
+ if (VF.isScalable()) {
----------------
`MaxVF`? because Elts is implied.
================
Comment at: llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:3500
+ if (VF.isScalable()) {
+ if (std::optional<unsigned> MaxVScale = TTI.getMaxVScale())
+ MaxVFElts *= *MaxVScale;
----------------
We so need to get rid of `TTI::getMaxVScale()`. I think function attributes should take precedence but then this is the order used within `getMaxLegalScalableVF` so perhaps best fixed separately. Up to you.
================
Comment at: llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:3503
+ else if (TheFunction->hasFnAttribute(Attribute::VScaleRange))
+ MaxVFElts *= *TheFunction->getFnAttribute(Attribute::VScaleRange)
+ .getVScaleRangeMax();
----------------
I suppose this can overflow. Perhaps make `MaxVFElts` an `uint64_t` given that's what `ugt` will promote to anyway.
================
Comment at: llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:8970
+ ElementCount::isKnownLT(VF, Range.End); VF *= 2)
+ IVUpdateCannotOverflow &= CM.isIndvarOverflowCheckKnownFalse(VF);
+
----------------
Is `addCanonicalIVRecipes` being passed the "wrong" tail folding style a functional issue? or just a corner case that might affect performance.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D142894/new/
https://reviews.llvm.org/D142894
More information about the llvm-commits
mailing list