[PATCH] D79783: [LoopVectorize] Fallback to a scalar epilogue when TP fails
Sjoerd Meijer via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed May 27 07:33:13 PDT 2020
SjoerdMeijer added a comment.
Hi @Ayal , with a bit of delay, I am almost ready to pick this up. Regarding your comments on rG9529597cf4562c64034943dacc29a4ff4fe93d86 <https://reviews.llvm.org/rG9529597cf4562c64034943dacc29a4ff4fe93d86>, I've copied them here below as I thought that would be more convenient, but let me know if you would like to move it to elsewhere. Anyway, I am now going to look into your comments, these ones:
> This omission of Primary Induction Phi's from Scalars in collectLoopScalars(), under foldTail:
>
> // An induction variable will remain scalar if all users of the induction
> // variable and induction variable update remain scalar.
> ...
> + // If tail-folding is applied, the primary induction variable will be used
> + // to feed a vector compare.
> + if (Ind == Legal->getPrimaryInduction() && foldTailByMasking())
> + continue;
>
>
> should have led widenIntOrFpInduction() to take the following early-exit for Phi's that are not in Scalars:
>
> // Try to create a new independent vector induction variable. If we can't
> // create the phi node, we will splat the scalar induction variable in each
> // loop iteration.
> if (!shouldScalarizeInstruction(EntryVal)) {
>
>
> rather than reaching CreateSplatIV() at the end.
>
> Perhaps the regressions occur when EntryVal is the Trunc rather than the IV Phi?
> If so, one remedy may be to also omit Trunc from Scalars; another may be to check if (!shouldScalarizeInstruction(IV) instead-of or in addition to if (!shouldScalarizeInstruction(EntryVal)).
>
> Is there a short reproducer?
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D79783/new/
https://reviews.llvm.org/D79783
More information about the llvm-commits
mailing list