[PATCH] D125810: [LV] Do not LoopSimplify/LCSSA after generating main vector loop.

Florian Hahn via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue May 17 14:26:59 PDT 2022


fhahn added a comment.

In D125810#3520608 <https://reviews.llvm.org/D125810#3520608>, @bmahjour wrote:

> IIRC the reason for calling `formLCSSARecursively` was to make sure we can handle live outs and reductions properly, which we seem to still be able to do (based on LIT test updates).

Thank you very much for checking! I *think* that should be save, as any checks should only rely on LCSSA phis in the original scalar loop and that loop remains unchanged. We add incoming values to the LCSSA phis, but that should leave LCSSA form of the original scalar loop intact.

> The call to `simplifyLoop` was to ensure we don't trip any assumptions about loop simplify form when processing the epilogue loop. It may not be an issue now, but would it be a problem, say if a hypothetical utility function common to both paths wants to assert that the loop is in simplified form? Is keeping `simplifyLoop()` harmless to VPlan's modeling of exit values?

I think it is actually `simplifyLoop` that's the main issue. It will create a new exit block that only has predecessors in the scalar loop. After code generation for the main vector loop, the original exit block will have predecessor outside the scalar loop (the "middle" block). And for the new exit block we need to fix LCSSA form for this block. Those new LCSSA phis would complicate things in D123537 <https://reviews.llvm.org/D123537>, because the VPlan would still reference the old LCSSA phi nodes, whereas we would need to update the new LCSSA nodes when generating code for the epilogue.

Over the last few years, LV has continually moved towards materializing all information required for code-generation in VPlan and I think introducing a new reliance on loop-simplify form during vector code generation would be problematic in general, as it would introduce a new dependence on the original IR. In terms of current code-generation it should be fine, as we don't actually generate code in the exit block of the scalar loop, we just update the phis.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D125810/new/

https://reviews.llvm.org/D125810



More information about the llvm-commits mailing list