When the an underlying value is available, we can use its name for
printing, as discussed in D73078.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Transforms/Vectorize/VPlan.cpp | ||
---|---|---|
589 | If now every VPValue that wraps a Value clearly says so in its name, does it hopefully make this "%vpA := %irX" part of "where:" redundant? | |
819 | Even if UV does not have a name, could we still indicate that VPValue wraps it; possibly by calling UV->printAsOperand()? |
Updated to use Value::printAsOperand for all VPValues with underlying values.
The new format uses '%vp.ir.<underlying value name>' for non-constant underlying values. It seems we have to do a bit of extra work to drop the % from the printed name. getName() would just return the string, but we also want to include implicitly numbered IR values.
For constant values, it prints 'ir constant <constant value>'. Not sure if calling out that it's an IR constant is required though.
It also adds a hasResult() method to VPInstruction, because printAsOperand does not make sense on IR values of type void. The method is subsequently used to avoid printing a result name for VPInstruction with underlying values of void ty.
llvm/lib/Transforms/Vectorize/VPlan.cpp | ||
---|---|---|
589 | I can drop that in a follow-up, if that's ok? | |
819 | Done! It required to add special handling for constants and also a bit of code to drop the % printed by printAsOperand, but now all underlying IR values should be printed consistently. A full list of the required changes can be found in the update comment. |
llvm/lib/Transforms/Vectorize/VPlan.cpp | ||
---|---|---|
409 | Better call printAsOperand(O, SlotTracker) only when needed, i.e., if (hasResult()) { printAsOperand(O, SlotTracker); O << " = "; } | |
589 | Sure, by all means. | |
819 | Thanks! And for VPValues w/o ingredients, print "vp<%x>" where x is the number assigned by SlotTracker? Currently this should be only BackedgeTakenCount, which ought to be assigned a meaningful name... | |
892 | Suffice to check now instead if (!UV) | |
llvm/lib/Transforms/Vectorize/VPlan.h | ||
739 | Better look at the VPInstruction's Opcode to determine if it has a result? | |
1479 | Better record the underlying ingredient to be used when printing, by doing new VPValue(V) instead. |
llvm/lib/Transforms/Vectorize/VPlan.cpp | ||
---|---|---|
819 | Yes that format simplifies things. I think it looks OK as well. | |
892 | If V is a VPInstruction, we should also only number instructions with results. Should be fixed | |
llvm/lib/Transforms/Vectorize/VPlan.h | ||
739 | I wanted to avoid to have such a check here initially, but it does not look too bad. Unless I missed an instruction, I think calls should be the only instruction where the opcode does not determine if it has a result or not. But just assuming calls have results should be fine. Plenty of instructions without result are not likely to be VPInstructions, but I guess it does not hurt to include them here. | |
1479 | Also better as a follow up? |
This looks good to me, thanks!
Added some minor final comments.
llvm/lib/Transforms/Vectorize/VPlan.cpp | ||
---|---|---|
893 | Right. May be easier to read if reversed into an early-exiting if (UV || (VPI && !VPI->hasResult())) return; At some point it would be good to name VPValues (w/o underlying Values). These would need SlotTracker's attention, to break name reuses. | |
llvm/lib/Transforms/Vectorize/VPlan.h | ||
739 | Sure. Some of these cannot be processed by LV. Would be good to switch back to something like "!getType()->isVoidTy()", once [VP]Types are introduced into VPlan/VPValue. | |
1479 | Very well. |
Thanks. I'll prepare the follow-ups shortly.
llvm/lib/Transforms/Vectorize/VPlan.h | ||
---|---|---|
739 | Sounds good! |
Better look at the VPInstruction's Opcode to determine if it has a result?