[PATCH] D76992: [VPlan] Add & use VPValue operands for VPWidenRecipe (NFC).

[Florian Hahn via Phabricator via llvm-commits]

fhahn marked an inline comment as done.
fhahn added a comment.

In D76992#1951192 <https://reviews.llvm.org/D76992#1951192>, @Ayal wrote:

> Thanks for following-up quickly. The part that extends VPWidenRecipe to have a User for holding its VPValue operands looks ok, but could the patch make sure that these operands are indeed used correctly by ILV::widenInstruction(), instead of moving the latter over to its execute()? The former may involve refactoring the case that deals with Calls, to record cost-based UseVectorInstrinsic/NeedToScalarize decisions when constructing the VPlan/recipe rather than during codegen; to record InvariantCond of Selects instead of accessing getSCEV(I.getOperand(0)) during codegen, possibly cleaning up to generate ScalarCond OR Cond but not both. In any case, accesses to I’s operands should all change to access User's operands instead, possibly with their underlying ingredient if needed.


The main reason for moving it into the recipe is so we can use getUnderlyingValue when lowering calls. A cleaner solution to deal with call would be to move them to their own recipe/instruction and record the required info as suggested. Is that along the line you suggest? I.e. something like the following: Move calls to their own recipe (NFC) and then move VPWidenRecipe and VPCallRecipe to VPUser in parallel?

Without changes to the call handling, I am not sure how we would be able to use the existing logic (unless we expose getUnderlyingValue to ILV.



================
Comment at: llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:7360
+      for (unsigned i = 0, ie = CI->getNumArgOperands(); i != ie; ++i) {
+        VPValue *Arg = User.getOperand(i);
+        // Some intrinsics have a scalar argument - don't replace it with a
----------------
Ayal wrote:
> Instead of accessing CI->getNumArgOperands(), get the number of User’s operands; or simply iterate over them?
CallInsts have their arguments first, followed by the called function, followed by operand bundles. Currently they will all be added to User. We could check the function type to see how many operands the call passes, but that might not work for variadic calls.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76992