Compiler has an analysis for perfect diamond matching but it does not
support nodes with main/alternate opcodes. The problem is that the
scalars themselves are different and might not match directly with other
nodes, but operands and main/alternate opcodes might match and compiler
might reuse some previously emitted vector instructions. Need to include
this analysis in the cost model and actual vector instructions emission
process.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp | ||
---|---|---|
5049 | I don't want to add an extra member function to keep the interface and contract of the class as simple as possible. Currently, we have just a single user for this functor, If we'll need to use in other places, I'll transform it into a member function. | |
5054–5063 | Will try but not sure we can represent it as operator==(). It is not an equality of the entries themselves, it is about equality of the operands. |
llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp | ||
---|---|---|
5049 | Nit: Perhaps rename ExistsMatchingNode to something a bit less ambiguous, for example like FoundDiamondMatch or FoundMatchingShuffle ? |
llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp | ||
---|---|---|
5049 | Ok, will rename it. |
This broke building a number of projects for me. It's reproducible with https://martin.st/temp/aom-preproc.c.
Building that file like this, fails an assertion:
$ bin/clang -target x86_64-w64-mingw32 -w -c -O2 aom-preproc.c clang: ../include/llvm/IR/User.h:170: llvm::Value* llvm::User::getOperand(unsigned int) const: Assertion `i < NumUserOperands && "getOperand() out of range!"' failed.
I'd suggest reverting this commit later today.
Yes, was able to reproduce it and have a fix. Going to revert the patch and will commit a fixed version tomorrow.
I think a better place for this function is in BoUpSLP, there are methods that search the tree entries there, like findReusedOrderedScalars(TE).