This is an archive of the discontinued LLVM Phabricator instance.

[VPlan] Use VPValue def for VPMemoryInstructionRecipe.
ClosedPublic

Authored by fhahn on Jul 27 2020, 10:35 AM.

Details

Summary

This patch turns VPMemoryInstructionRecipe into a VPValue and uses it
during VPlan construction and codegeneration instead of the plain IR
reference where possible.

Diff Detail

Event Timeline

fhahn created this revision.Jul 27 2020, 10:35 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 27 2020, 10:35 AM

I could not find a review for VPWidenRecipe, so I put one up in D88447, that also has some adjustment for how VPValues are registered.

llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
560–561

There's an extra newline here, that looks like it came from a merge conflict.

7328

It might be worth thinking about doing this after the call to RecipeBuilder.tryToCreateWidenRecipe, so that it's done for all recipes at once.

llvm/lib/Transforms/Vectorize/VPlan.h
1225–1228

Would we want to make this inherit from VPUser as well?

1640

Most variables here have a comment.

fhahn updated this revision to Diff 295358.Sep 30 2020, 11:07 AM

Rebased & addressed comments, thanks!

I could not find a review for VPWidenRecipe, so I put one up in D88447, that also has some adjustment for how VPValues are registered.

That was indeed missing, thanks for putting up the patch.

fhahn updated this revision to Diff 295390.Sep 30 2020, 1:15 PM

Move adding VPValue to plan up.

fhahn added inline comments.Sep 30 2020, 1:18 PM
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
560–561

That's odd, it seems like clang-format did miss this one. Should be fixed now.

7328

We should definitely do that, but I'd thought it would be best to do so once we migrated most/all recipes.

I updated the code to try to convert the recipe to a VPValue after tryToCreateWidenRecipe. Unfortunately we won't eb able to use isa/cast/dyn_cast until VPRecipeBase inherits from VPValue, because otherwise we would cast between types that are not connected through inheritance. The main advantage would be to have a single place to update after the switch.

llvm/lib/Transforms/Vectorize/VPlan.h
1225–1228

I've pushed a commit updating all classes that have a VPUser member to instead inherit from VPUser, which we should be able to do independently now that VPuser is not a VPValue (for now)

1640

I added a comment.

dmgreen accepted this revision.Oct 2 2020, 9:06 AM

Thanks. This looks good to me, and I like the direction we are heading towards.

You might of course want to wait a day or two in case others disagree.

llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
7328

The new code looks OK I think, at least in the sort term.

llvm/lib/Transforms/Vectorize/VPlan.h
1225–1228

Yeah I saw. Looks good.

This revision is now accepted and ready to land.Oct 2 2020, 9:06 AM
fhahn updated this revision to Diff 296176.Oct 5 2020, 7:19 AM

Thanks for taking a look! I rebased the patch and updated it with a change to replace all uses of VPWidenMemoryInstructionRecipe VPValues when replacing it with a VPInterleaveRecipe.

I'll update the follow-on patches shortly as well, they should now be finished in terms of functionality.

fhahn updated this revision to Diff 296223.Oct 5 2020, 10:44 AM

Add getUnderlyingInstr to VPRecipeBase, using toVPValue.

dmgreen added inline comments.Oct 6 2020, 1:10 AM
llvm/lib/Transforms/Vectorize/VPlan.cpp
932–933

This looks like it will print mask twice.

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

Hmm. I had not considered exposing getUnderlyingInstr at this level. I suppose that should work. Not all recipes with have Instructions and some of them might want different accessors returning the correct type (Phi's or GEP's etc).

The cast<Instruction> below should be dyn_cast_or_null<Instruction> if the method is expected to return nullptr.

There is a comment above getUnderlyingValue that says

// DESIGN PRINCIPLE: Access to the underlying IR must be strictly limited to
// the front-end and back-end of VPlan so that the middle-end is as
// independent as possible of the underlying IR. We grant access to the
// underlying IR using friendship. In that way, we should be able to use VPlan
// for multiple underlying IRs (Polly?) by providing a new VPlan front-end,
// back-end and analysis information for the new IR.

I'm not sure if I agree with that design principle, and wouldn't mind that comment being removed and getUnderlyingValue being exposed as public (it can make matching things like constants easier to recognise). If not then the same would apply here.

fhahn updated this revision to Diff 296418.Oct 6 2020, 5:18 AM

Remove additional printing of the mask. Should be included when printing all operands

fhahn updated this revision to Diff 296421.Oct 6 2020, 5:28 AM

make getUnderlyingInstr protected.

fhahn added inline comments.Oct 6 2020, 5:35 AM
llvm/lib/Transforms/Vectorize/VPlan.cpp
932–933

Oh right, that's not need any more.

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

Hmm. I had not considered exposing getUnderlyingInstr at this level. I suppose that should work. Not all recipes with have Instructions and some of them might want different accessors returning the correct type (Phi's or GEP's etc).

The cast<Instruction> below should be dyn_cast_or_null<Instruction> if the method is expected to return nullptr.

I think this should only be called from inside recipes that actually set the underlying value. I think it's fine to crash/assert otherwise. I think we can even push the responsibility to the caller to only use it for VPValues with an underlying value that is an instruction.

I'm not sure if I agree with that design principle, and wouldn't mind that comment being removed and getUnderlyingValue being exposed as public (it can make matching things like constants easier to recognise). If not then the same would apply here.

yeah, we should probably at least make those helpers protected, so they can only be used from within recipes. I think the long term goal is to de-couple the vpvalues/recipes so far from IR that we can generate IR without relying on references to the original IR.

Unfortunately, many recipes rely on some information attached to the original IR instructions (mostly for type info, but some other things too). I think it is beneficial to use VPValue's underlying value for the related IR instruction, as it allows us to get rid of the duplicated recipe-specific IR pointer and we also do not have to worry about the underlying value and other reference to diverge.

I made the functions protected, so the comment above still kind-of applies (and we were doing the same thing for VPInstruction already).

fhahn updated this revision to Diff 296427.Oct 6 2020, 5:48 AM

use cast_or_null in getUnderlyingInstr.

fhahn added inline comments.Oct 6 2020, 5:49 AM
llvm/lib/Transforms/Vectorize/VPlan.h
696

I think this should only be called from inside recipes that actually set the underlying value. I think it's fine to crash/assert otherwise. I think we can even push the responsibility to the caller to only use it for VPValues with an underlying value that is an instruction.

On second though, I think in some later patches actually make use of getUnderlyingInstr to return nullptr for non-VPValue. This should lead to slightly simpler code during the transition. Also made it cast_or_null.

fhahn updated this revision to Diff 297609.Oct 12 2020, 9:04 AM

Rebased again. I plan to land this shortly to get things rolling.

This revision was landed with ongoing or failed builds.Oct 12 2020, 10:04 AM
This revision was automatically updated to reflect the committed changes.
vitalybuka added inline comments.
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
7821
vitalybuka reopened this revision.Oct 13 2020, 3:01 AM
This revision is now accepted and ready to land.Oct 13 2020, 3:01 AM
fhahn added inline comments.Oct 14 2020, 1:43 PM
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
7821

Thanks! Recommitted with a fix and it seems like the staging msan bit is happy now

fhahn closed this revision.Nov 9 2020, 4:09 AM

Just realized I never closed this one with the re-commit. Recommitted a while ago as 93f6c6b79c500