Update generateInstruction to return the produced value instead of
setting it for each opcode. This reduces the amount of duplicated code
and is a preparation for D153696.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Thanks for following-up on this!
Adding some comments to hopefully further simplify and clarify the roles of generateInstruction() vs. execute().
llvm/lib/Transforms/Vectorize/VPlan.h | ||
---|---|---|
850–854 | This method should arguably always generate an Instruction and return it. What to do with the generated Instruction, when this recipe !hasResult, could be left to the caller. | |
llvm/lib/Transforms/Vectorize/VPlanRecipes.cpp | ||
275 | Note that in this case an existing Value is returned rather than a newly generated Instruction. | |
290 | Once the caller recognizes this as a uniform recipe, it should call it with Part zero only, and this "if" should be replaced by an assert. | |
307 | Another case where an existing Value is returned instead of a newly generated instruction. | |
316 | Once the caller recognizes this as a uniform recipe, it should call it with Part zero only, and this "if" should be replaced by an assert. | |
333 | Perhaps better return CondBr, i.e., have generateInstruction() always return the instruction it generates (or an existing Value) and have the caller reason about setting it in State if hasResult/users or not? | |
337 | Once the caller recognizes this as a uniform recipe, it should call it with Part zero only, and this "if" should be replaced by an assert. | |
357 | Better return CondBr? | |
370 | Check instead if (!hasResult() - also considers e.g. stores) or !have any user? |
Address latest comments, thanks!
llvm/lib/Transforms/Vectorize/VPlan.h | ||
---|---|---|
850–854 | updated thanks! | |
llvm/lib/Transforms/Vectorize/VPlanRecipes.cpp | ||
290 | Will do thanks! | |
307 | Right, builder fold should be added in D152660. | |
316 | Will do, thanks! | |
333 | Updated, thanks! | |
337 | Will do, thanks! | |
357 | updated, thanks! | |
370 | Updated to check hasResult, thanks! |
This method should arguably always generate an Instruction and return it. What to do with the generated Instruction, when this recipe !hasResult, could be left to the caller.
Cases that currently do not generate any instruction should be optimized away by (a) having the caller recognize that a single value is needed per all parts, and (b) hooking up existing values directly to their users w/o going through a VPInstruction. These can be dealt with separately, by subsequent patches.