[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