[PATCH] D101916: [LoopVectorize] Fix crach for predicated instruction with scalable VF
David Sherwood via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu May 6 00:57:18 PDT 2021
david-arm added inline comments.
================
Comment at: llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:7792
+ continue;
+ if (isScalarWithPredication(&I))
+ return true;
----------------
sdesmalen wrote:
> There is a problem with this approach, in that `isScalarWithPredication` calls `blockNeedsPredication`, which in turn calls `foldTailByMasking`, whose return value is determined //after// calling `computeFeasibleMaxVF`, which ends up calling this function in order to determine the min/max VF. This may lead to unexpected results when we want to use scalable vectors for tail-folded (predicated) loops, so you'll need to figure out a better place to call `loopHasPredicatedScalar`.
>
> Additionally, it might be useful to add a mechanism that records if FoldTailByMasking already has its final value, and then assert that in `isScalarWithPredication`.
OK that's a good point. It's tricky because we also need to ensure we call this before attempting to calculate any costs as we'll hit asserts in computePredInstDiscount again. If we didn't have to worry about `blockNeedsPredication`, this seems like a sensible place to bail out because we have to also worry about the general case without hints, i.e. we should really be telling the computeMaxVF code the max legal scalable VF = 0 as I believe this is how you've been recently structuring the code to work?
I realise this is not an ideal solution, but what if for now we could avoid concerns about tail folding by somehow marking tail folding as not an option for scalable vectors, since we don't support it anyway for scalable vectors?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D101916/new/
https://reviews.llvm.org/D101916
More information about the llvm-commits
mailing list