This is an archive of the discontinued LLVM Phabricator instance.

[VPlan] Use underlying value for printing, if available.
ClosedPublic

Authored by fhahn on Mar 15 2020, 12:02 PM.

Details

Summary

When the an underlying value is available, we can use its name for
printing, as discussed in D73078.

Diff Detail

Event Timeline

fhahn created this revision.Mar 15 2020, 12:02 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 15 2020, 12:02 PM
Ayal added inline comments.Mar 15 2020, 1:47 PM
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()?

fhahn updated this revision to Diff 250516.Mar 16 2020, 4:11 AM

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.

fhahn marked 3 inline comments as done.Mar 16 2020, 4:13 AM
fhahn added inline comments.
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.

Ayal added inline comments.Mar 17 2020, 8:38 AM
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!
Could this be simplified, by always printing "ir<X>" where X is whatever printAsOperand provides, which could be ir<%tmp>, ir<%5>, ir<7>, ir<void>, letting the caller worry about not printing void?

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.

fhahn updated this revision to Diff 251098.Mar 18 2020, 8:39 AM
fhahn marked 8 inline comments as done.

Address Ayal's comments, thanks!

fhahn added inline comments.Mar 18 2020, 8:40 AM
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?

Ayal accepted this revision.Mar 18 2020, 9:40 AM

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.

This revision is now accepted and ready to land.Mar 18 2020, 9:40 AM
fhahn marked 2 inline comments as done.Mar 18 2020, 10:49 AM

Thanks. I'll prepare the follow-ups shortly.

llvm/lib/Transforms/Vectorize/VPlan.h
739

Sounds good!

This revision was automatically updated to reflect the committed changes.