[PATCH] D74695: [VPlan] Replace VPWidenRecipe with VPInstruction (WIP).

Wed Mar 18 11:25:01 PDT 2020

fhahn planned changes to this revision.
fhahn added a comment.

In D74695#1926674 <https://reviews.llvm.org/D74695#1926674>, @gilr wrote:

> In D74695#1923526 <https://reviews.llvm.org/D74695#1923526>, @fhahn wrote:
>
> > I think doing so for VPWidenRecipe might be more tricky than other recipes, as VPWidenRecipe currently contains a list of instructions.
> >  [snip]
> >  I thought a little bit about how to migrate the def-use dependencies for VPWidenRecipe without breaking it up, but couldn't come up with a more straight-forward approach.
>
>
> VPWidenRecipe wrapped intervals of ingredients just to keep VPlan's memory footprint low. Now that we begin to model def-use relations this mechanism will have to go (it's already suppressed for sink-after). We can start by removing compression altogether in a preliminary patch, turning VPWidenRecipe into a single-ingredient recipe, ready to take VPValue operands.
>  A following patch can add VPValue operands to VPWidenRecipe by calling `getOrAddVPValue()` for each IR operand, similar to D70865 <https://reviews.llvm.org/D70865>.
>  The next patch (perhaps also in parts) can replace VPWidenRecipes with VPInstructions by
>  (a) binding VP defs to IR users, as proposed
>  (b) extending the usage of `recordRecipe()` to ingredients covered by VPInstructions such that calling `getRecipe()` will return either a VPInstruction, another Recipe or nullptr. For the latter two cases, call `getOrAddVPValue()`.
>  (c) refactoring VPWidenRecipe's execute()
>  What do you think?

That sounds good. I'll break up the patch along the lines suggested ASAP.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74695