[llvm-branch-commits] [llvm] 0d15d4b - [SLP] use operand index abstraction for number of operands

[Sanjay Patel via llvm-branch-commits]

Author: Sanjay Patel
Date: 2020-12-22T16:05:39-05:00
New Revision: 0d15d4b6f43a3355c1d618766c8e550cfe1481d0

URL: https://github.com/llvm/llvm-project/commit/0d15d4b6f43a3355c1d618766c8e550cfe1481d0
DIFF: https://github.com/llvm/llvm-project/commit/0d15d4b6f43a3355c1d618766c8e550cfe1481d0.diff

LOG: [SLP] use operand index abstraction for number of operands

I think this is NFC currently, but the bug would be exposed
when we allow binary intrinsics (maxnum, etc) as candidates
for reductions.

The code in matchAssociativeReduction() is using
OperationData::getNumberOfOperands() when comparing whether
the "EdgeToVisit" iterator is in-bounds, so this code must
use the same (potentially offset) operand value to set
the "EdgeToVisit".

Added: 
    

Modified: 
    llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp

Removed: 
    


################################################################################
diff  --git a/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp b/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
index b03fb203c6d7..baa8ce2638a0 100644
--- a/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
+++ b/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
@@ -6772,7 +6772,8 @@ class HorizontalReduction {
       // in this case.
       // Do not perform analysis of remaining operands of ParentStackElem.first
       // instruction, this whole instruction is an extra argument.
-      ParentStackElem.second = ParentStackElem.first->getNumOperands();
+      OperationData OpData = getOperationData(ParentStackElem.first);
+      ParentStackElem.second = OpData.getNumberOfOperands();
     } else {
       // We ran into something like:
       // ParentStackElem.first += ... + ExtraArg + ...