This is an archive of the discontinued LLVM Phabricator instance.

[LV] Use PHI recipe instead of PredRecipe for subsequent uses.
ClosedPublic

Authored by fhahn on Jul 9 2022, 8:05 PM.

Details

Summary

At the moment, the VPPRedInstPHIRecipe is not used in subsequent uses of
the predicate recipe. This incorrectly models the def-use chains, as all
later uses should use the phi recipe. Fix that by delaying recording of
the recipe.

Diff Detail

Event Timeline

fhahn created this revision.Jul 9 2022, 8:05 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 9 2022, 8:05 PM
Herald added a subscriber: hiraditya. · View Herald Transcript
fhahn requested review of this revision.Jul 9 2022, 8:05 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 9 2022, 8:05 PM
Ayal added inline comments.Jul 12 2022, 8:12 AM
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
8474

Above use of Op is unrelated to the fix, right?

8475–8478

There seems to be some redundancy left here?

8481

Re-associating Instr with PHIRecipe instead of some previous VPValue (i.e., PredRecipe) via removeVPValueFor()/addVPValue() in order to affect subsequent get[OrAdd]VPValue()'s, seems aligned with re-associating setRecipe() to affect subsequent getRecipe()'s. Should we retain the initial setRecipe() which aligns with initial addVPValue(), and introduce the ability to resetRecipe() here? Can also replace removeVPValue()(+addVPValue()) with replaceVPValue(). The other (two) instances of removeVPValue()/addVPValue() pairs, namely adjustRecipesForReductions() and when transforming InterleaveGroups, should not resetRecipe(), right?

llvm/test/Transforms/LoopVectorize/first-order-recurrence-sink-replicate-region.ll
474

Should VPlan's def/use verification checks and/or splice/FOR/header-phi recipes assert that values across the backedge are indeed such?

fhahn updated this revision to Diff 444464.Jul 13 2022, 5:16 PM
fhahn marked 3 inline comments as done.

Simplify code.

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

This is actually an unnecessary change in the latest version of the patch, removed! But it turns out that the call to getOrAddVPValue is actually unnecessary and we can use PredRecipe instead: 6f7347b888a4

8475–8478

Yes, cleaned up! Only setRecipe remains.

8481

Adding a resetRecipe would be an option, but resetting a VPValue/recipe should only be an exception. In this case it seems cleaner to just delay setting it. WDYT?

llvm/test/Transforms/LoopVectorize/first-order-recurrence-sink-replicate-region.ll
474

I think a check that defs dominate uses would catch that in general without the need for special handling. It might be possible to extend the verifier without fully fledged VP dominator support.

Ayal added inline comments.Jul 13 2022, 9:52 PM
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
8417–8418

This addVPValue was next to setRecipe; could it too sink to remain next to it?

8456–8459

nit: can avoid passing Instr given that it's underlying PredRecipe.

8481

Agreed, but would be good to align (re)setRecipe with (remove)addVPValue; could the latter also be delayed, considering the cleaned-up call to getOrAddVPValue?

fhahn updated this revision to Diff 444688.Jul 14 2022, 8:58 AM

Address latest comments, thanks!

fhahn marked 3 inline comments as done.Jul 14 2022, 9:04 AM
fhahn added inline comments.
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
8417–8418

Ah yes, this can be sunk, removing the need for the later removeVPValue!

8456–8459

Simplified, thanks!

8481

In the latest version there's no need for resetting, as the addVPValue can also be delayed until this point.

Ayal added inline comments.Jul 14 2022, 1:55 PM
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
8417–8418

Very well!

8456–8459

Very well!

8481

Even better.

Should also Plan->addVPValue(Instr, PredRecipe) here, retaining existing behavior? Or OTOH if Instr->getType()->isVoidTy() perhaps neither addVPValue nor setRecipe are needed for it?

fhahn marked 4 inline comments as done.Jul 14 2022, 2:02 PM
fhahn added inline comments.
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
8481

Plan->addVPValue(Instr, PredRecipe)

Given that Instr doesn't have a result value (due to void type) there is no need to add the VPValue here. I think setRecipe is still needed, in case something needs to be moved after the recipe for Instr.

Ayal added inline comments.Jul 15 2022, 1:25 PM
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
8417–8418

This patch deals with setRecipe() being done here too early w/o being reset later, erroneously. addVPValue is also done here too early - whether I defines a value or returns void, is predicated or not - but is reset correctly later. It would be good to keep the two together, so if the fix for setRecipe is to postpone it - move addVPValue as well. However, avoiding a redundant addVPValue when I returns void calls for a separate patch?

8481

ok, best for this patch to retain current addVPValue behavior and focus on fixing setRecipe bug only? Separating the potential removal of addVPValue for result-less Instr's, and possibly that of setRecipe as well (the two should arguably be merged) to a subsequent patch, as noted above?

fhahn updated this revision to Diff 445309.Jul 17 2022, 3:31 AM
fhahn marked 4 inline comments as done.

Also use addVPValue when type is void.

llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
8417–8418

r. It would be good to keep the two together, so if the fix for setRecipe is to postpone it - move addVPValue as well. However, avoiding a redundant addVPValue when I returns void calls for a separate patch?

Sounds good, I added addVPValue in the else branch as well below, to be removed separately.

8481

Sounds good, I added the addVPValue to the else branch as well here.

Ayal accepted this revision.Jul 17 2022, 10:00 AM

Thanks!!
LGTM, Ship it.

This revision is now accepted and ready to land.Jul 17 2022, 10:00 AM
This revision was landed with ongoing or failed builds.Jul 18 2022, 1:35 AM
This revision was automatically updated to reflect the committed changes.