[PATCH] D29900: [SLP] Fix for PR31879: vectorize repeated scalar ops that don't get put back into a vector

Hal Finkel via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Feb 13 12:16:46 PST 2017


hfinkel added inline comments.


================
Comment at: lib/Transforms/Vectorize/SLPVectorizer.cpp:1672
           Instruction *E = cast<Instruction>(VL[i]);
-          if (E->hasOneUse())
+          if (hasOneUse(E))
             // Take credit for instruction that will become dead.
----------------
ABataev wrote:
> hfinkel wrote:
> > Why are we checking this use(r) count at all? If canReuseExtract is true, then don't we just care that all users are part of the to-be-vectorized tree?
> > 
> It does not check if we can vectorize extract, it checks should we remove this extract from the code or there are other users of this extract. If we can remove this extract from the code, we can consider this instruction as dead and subtract from the cost, otherwise this instruction is alive and its cost should be considered during vectorization.
Right, but what's special in this regard about all of the uses belonging to the same instruction? What if the test case, for example, looked like this:


  %x0 = extractelement <2 x float> %x, i32 0
  %x1 = extractelement <2 x float> %x, i32 1
  %x0x1 = fmul float %x0, %x1
  %x1x1 = fmul float %x1, %x1
  %add = fadd float %x0x1, %x1x1
  ret float %add
}

are the costs of all of these extracts still accounted for correctly? The final code presumably has a shuffle in place of one of the extracts?




https://reviews.llvm.org/D29900





More information about the llvm-commits mailing list