[PATCH] D84679: [VPlan] Disconnect VPValue and VPUser.

[Florian Hahn via Phabricator via llvm-commits]

fhahn added a comment.



>> Thanks for sharing. As mentioned earlier, the main reason at the moment is to ensure a step-by-step transition and once all recipes are migrated the common class can be hoisted to `VPRecipeBase`. I hope the explanation makes sense.
>
> Like I said I'm happy that we are moving towards the ability to do this better. It will be good to see VPlan being able to start to make some real improvements! If we are happy enough with this way of doing things, at least currently, then I can go and make some more sensibly sized patches :)

I experimented a bit more and came up with another alternative: allow VPValue to model 3 different things: 1) concrete VPValues, 2) sub VPValues and 3) virtual VPValue: D88380 <https://reviews.llvm.org/D88380>

Managing those 3 in VPValue directly simplifies things further down a bit and I put up 2 more follow-on patches that turn VPReciepBase into a VPValue (D88379 <https://reviews.llvm.org/D88379>) and then also a VPUser (D88378 <https://reviews.llvm.org/D88378>). The last one also contains a unit test that looks upwards & downwards along the def-use chains. Note that we should probably move most/all remaining recipes to be VPValues and manage operands as VPUser before the last 2 patches.

Overall this probably results in a simpler structure overall. If we want, we could then also fold VPUser into VPRecipeBase.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D84679/new/

https://reviews.llvm.org/D84679