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
590

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?

820

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
590

I can drop that in a follow-up, if that's ok?

820

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
408

Better call printAsOperand(O, SlotTracker) only when needed, i.e.,

if (hasResult()) {
  printAsOperand(O, SlotTracker);
  O << " = ";
}
590

Sure, by all means.

820

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...

889

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?

1491

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
820

Yes that format simplifies things. I think it looks OK as well.

889

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.

1491

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
890

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.

1491

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.