search for: loopvectorizationplanner

Hi, I noticed that the dead instructions collected when build vplan are invariant to different ranges of VFs since the original loop is not changed. Maybe DeadInstructions should be treated as a data member of LoopVectorizationPlanner and initialized by collectTriviallyDeadInstructions() in plan()? Cheers, Shixiong (Jason) Xu -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180601/69f28841/attachment.html>

All, I'm trying to refactor LoopVectorize such that it has better conformance to VPlan vision going forward (http://www.llvm.org/docs/Proposals/VectorizationPlan.html). All VP*Recipe class definitions are now moved to VPlan.h, and I have a patch under review to move LoopVectorizationPlanner class out of LoopVectorize.cpp (https://reviews.llvm.org/D41420). Next thing I'm working on is LoopVectorizationLegality, and I noticed that it has a component of CostModel and optimization, which doesn't seem right from vectorizer's architectural perspective. It appears that we are cu...

...; > All, > > I'm trying to refactor LoopVectorize such that it has better conformance to VPlan vision going forward > (http://www.llvm.org/docs/Proposals/VectorizationPlan.html). All VP*Recipe class definitions are now > moved to VPlan.h, and I have a patch under review to move LoopVectorizationPlanner class out of > LoopVectorize.cpp (https://reviews.llvm.org/D41420). > > Next thing I'm working on is LoopVectorizationLegality, and I noticed that it has a component of > CostModel and optimization, which doesn't seem right from vectorizer's architectural perspective. >...

...All, > > I'm trying to refactor LoopVectorize such that it has better > conformance to VPlan vision going forward > (http://www.llvm.org/docs/Proposals/VectorizationPlan.html). All > VP*Recipe class definitions are now moved to VPlan.h, and I have a patch under review to move LoopVectorizationPlanner class out of LoopVectorize.cpp (https://reviews.llvm.org/D41420). > > Next thing I'm working on is LoopVectorizationLegality, and I noticed > that it has a component of CostModel and optimization, which doesn't seem right from vectorizer's architectural perspective. > It a...

...t;> I'm trying to refactor LoopVectorize such that it has better >> conformance to VPlan vision going forward >> (http://www.llvm.org/docs/Proposals/VectorizationPlan.html). All >> VP*Recipe class definitions are now moved to VPlan.h, and I have a patch under review to move LoopVectorizationPlanner class out of LoopVectorize.cpp (https://reviews.llvm.org/D41420). >> >> Next thing I'm working on is LoopVectorizationLegality, and I noticed >> that it has a component of CostModel and optimization, which doesn't seem right from vectorizer's architectural perspective....

...gt; I'm trying to refactor LoopVectorize such that it has better >> conformance to VPlan vision going forward >> (http://www.llvm.org/docs/Proposals/VectorizationPlan.html). All >> VP*Recipe class definitions are now moved to VPlan.h, and I have a patch under review to move LoopVectorizationPlanner class out of LoopVectorize.cpp (https://reviews.llvm.org/D41420). >> >> Next thing I'm working on is LoopVectorizationLegality, and I noticed >> that it has a component of CostModel and optimization, which doesn't seem right from vectorizer's architectural perspective...

...ut creating multiple, incompatible and potentially destructive whole > new pass managers will make a hard job impossible. I don't think the proposal qualifies as including a full-flexible new pass manger, at least no more than the current mechanism LoopVectorize uses to run passes on VPlan (LoopVectorizationPlanner::plan). > > However, it lacks cheap copies. Instead > > of instructions, it uses recipes/"meta-instructions" that handle what > > happens to instructions after vectorization, e.g. do that operation on > > each vector lane ("WIDEN"). > > Nothing st...

In the 2018 LLVM DevMtg [1], I presented some shortcomings of how LLVM optimizes loops. In summary, the biggest issues are (a) the complexity of writing a new loop optimization pass (including needing to deal with a variety of low-level issues, a significant amount of required boilerplate, the difficulty of analysis preservation, etc.), (b) independent optimization heuristics and a fixed pass