This patch turns VPMemoryInstructionRecipe into a VPValue and uses it
during VPlan construction and codegeneration instead of the plain IR
reference where possible.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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 | ||
---|---|---|
513 | There's an extra newline here, that looks like it came from a merge conflict. | |
6958 | 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 | ||
1167 | Would we want to make this inherit from VPUser as well? | |
1582 | Most variables here have a comment. |
Rebased & addressed comments, thanks!
That was indeed missing, thanks for putting up the patch.
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp | ||
---|---|---|
513 | That's odd, it seems like clang-format did miss this one. Should be fixed now. | |
6958 | 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 | ||
1167 | 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) | |
1582 | I added a comment. |
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 | ||
---|---|---|
6958 | The new code looks OK I think, at least in the sort term. | |
llvm/lib/Transforms/Vectorize/VPlan.h | ||
1167 | Yeah I saw. Looks good. |
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.
llvm/lib/Transforms/Vectorize/VPlan.cpp | ||
---|---|---|
821 | This looks like it will print mask twice. | |
llvm/lib/Transforms/Vectorize/VPlan.h | ||
681 | 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. |
Remove additional printing of the mask. Should be included when printing all operands
llvm/lib/Transforms/Vectorize/VPlan.cpp | ||
---|---|---|
821 | Oh right, that's not need any more. | |
llvm/lib/Transforms/Vectorize/VPlan.h | ||
681 |
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.
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). |
llvm/lib/Transforms/Vectorize/VPlan.h | ||
---|---|---|
681 |
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. |
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp | ||
---|---|---|
7424 | this is a memory leak |
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp | ||
---|---|---|
7424 | Thanks! Recommitted with a fix and it seems like the staging msan bit is happy now |
Just realized I never closed this one with the re-commit. Recommitted a while ago as 93f6c6b79c500
There's an extra newline here, that looks like it came from a merge conflict.