This is an archive of the discontinued LLVM Phabricator instance.

[SLP]Improve analysis/emission of vector operands for alternate nodes.
ClosedPublic

Authored by ABataev on Nov 17 2021, 9:21 AM.

Details

Summary

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.

Diff Detail

Event Timeline

ABataev created this revision.Nov 17 2021, 9:21 AM
ABataev requested review of this revision.Nov 17 2021, 9:21 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 17 2021, 9:21 AM
vporpo added inline comments.Nov 23 2021, 2:35 PM
llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
5049

I think a better place for this function is in BoUpSLP, there are methods that search the tree entries there, like findReusedOrderedScalars(TE).

5054–5063

Could you place these checks in a method in TreeEntry? Perhaps as an operator==() ?

ABataev added inline comments.Nov 24 2021, 5:19 AM
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.

ABataev updated this revision to Diff 389482.Nov 24 2021, 6:24 AM

Address comments

vporpo accepted this revision.Nov 24 2021, 10:46 AM
vporpo added inline comments.
llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
5049

Nit: Perhaps rename ExistsMatchingNode to something a bit less ambiguous, for example like FoundDiamondMatch or FoundMatchingShuffle ?

This revision is now accepted and ready to land.Nov 24 2021, 10:46 AM
ABataev added inline comments.Nov 24 2021, 10:49 AM
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.

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.

We're seeing the same problem in downstream bots.

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.