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 + ... _______________________________________________ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
