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.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
60,120 ms | x64 debian > Clang.Driver::emit-reproducer.c |
Event Timeline
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp | ||
---|---|---|
8465 | Above use of Op is unrelated to the fix, right? | |
8466 | There seems to be some redundancy left here? | |
8469 | 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? |
Simplify code.
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp | ||
---|---|---|
8465 | 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 | |
8466 | Yes, cleaned up! Only setRecipe remains. | |
8469 | 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. |
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp | ||
---|---|---|
8408–8409 | This addVPValue was next to setRecipe; could it too sink to remain next to it? | |
8447–8450 | nit: can avoid passing Instr given that it's underlying PredRecipe. | |
8469 | 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? |
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp | ||
---|---|---|
8469 |
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. |
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp | ||
---|---|---|
8408–8409 | 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? | |
8469 | 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? |
Also use addVPValue when type is void.
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp | ||
---|---|---|
8408–8409 |
Sounds good, I added addVPValue in the else branch as well below, to be removed separately. | |
8469 | Sounds good, I added the addVPValue to the else branch as well here. |
This addVPValue was next to setRecipe; could it too sink to remain next to it?