This is an archive of the discontinued LLVM Phabricator instance.

[SLP]Early exit out of the reordering if shuffled/perfect diamond match found.
ClosedPublic

Authored by ABataev on Dec 15 2021, 11:09 AM.

Details

Summary

Need to early exit out of the reordering process if the perfect/shuffled match is found in the operands. Such pattern will result in not profitable reordering because of (false positive) external use of scalars.

Diff Detail

Event Timeline

ABataev created this revision.Dec 15 2021, 11:09 AM
ABataev requested review of this revision.Dec 15 2021, 11:09 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 15 2021, 11:09 AM
vporpo added inline comments.Dec 15 2021, 12:06 PM
llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
1656–1665

Isn't VLOperands a better place for this logic? Perhaps a method like: isDiamondMatch() ?
This will also help separate the temporary check UniqueValues.size() == 2 || !isPowerOf2_32(UniqueValues.size()). What do you think?

1666

nit: Perhaps a TODO here?

ABataev added inline comments.Dec 15 2021, 12:14 PM
llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
1656–1665

I just thought that we may have this situation after the very first iteration of the reordering, not only initially.

1666

Will do

ABataev updated this revision to Diff 394651.Dec 15 2021, 1:24 PM

Added a comment

vporpo added inline comments.Dec 15 2021, 1:31 PM
llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
1656–1665

I am not sure I follow why moving this logic to a member method in VLOperands won't work in this case. Could you elaborate a bit on this?

ABataev added inline comments.Dec 15 2021, 1:33 PM
llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
1656–1665

I have the same problem because this function reorder() is a member of VLOperands class :)

ABataev added inline comments.Dec 15 2021, 2:46 PM
llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
1656–1665

Or do you suggest transforming this lambda to a member function? If so, I think keeping lambda is better because it does not increase the number of interfaces of the class. If (or when) we'll have several users of this functionality, it can be outlined into a private member function.

vporpo added inline comments.Dec 15 2021, 3:03 PM
llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
1656–1665

Yes, I was suggesting moving the loops of this lambda to a function. I understand that this is the only use so it is not really needed, but if we need this same functionality in the future it will be hard to remember that this code already exists in this lambda. So we will probably end up re-implementing it.

Anyway, regarding your earlier comment, sorry, I still don't understand what issue you are referring to about the first iteration of reordering. Are you referring to the Passes in the for loop? I am confused.

ABataev added inline comments.Dec 15 2021, 3:05 PM
llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
1656–1665

Yes, to passes in the loop. If the pass failed, we still do some reordering and may end up with the diamond match situation.

vporpo added inline comments.Dec 15 2021, 3:27 PM
llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
1656–1665

OK, but why do you want to avoid it if it happens in a later pass? Is it going to produce a worse reordering?

Do you think the diamond case could be handled by adding a new ReorderingMode::Diamond that disables reordering for those operand indexes (or perhaps disables reordering completely)? This could be set in the loop under // Initialize the modes., line 1627. This would also fit with the existing design and won't look like a workaround. What do you think?

ABataev added inline comments.Dec 15 2021, 3:35 PM
llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
1656–1665

OK, but why do you want to avoid it if it happens in a later pass? Is it going to produce a worse reordering?

I think it may.

Do you think the diamond case could be handled by adding a new ReorderingMode::Diamond ...

Not sure we can do it. We perform the analysis lane by lane, but here we need to perform the analysis in the orthogonal order - operand by operand.
We can implement some deeper analysis, probably, but it requires extra time to understand how to implement it.
Plus, this is not the analysis but a kind of corner case check. The analysis process is not aware of the diamond match and currently, it is pretty hard to teach it about it, need to change the design completely.

vporpo added inline comments.Dec 15 2021, 4:33 PM
llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
1656–1665

Are you planning to move the bail-out check before the pass loop then?

Also I would rename the lambda to something like SkipReordering because it is actually looking for corner cases when it should bail-out, it is not looking for cases when it should apply reordering. And please make sure that it is clear from the comment that this is the place where any code related to reordering bail-outs should be placed.

ABataev added inline comments.Dec 15 2021, 4:39 PM
llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
1656–1665

I intentionally moved it into the loop, because even if we failed to reorder all the operands/lanes, some of them still might be reordered and after the failed reordering attempt we still may have diamond match.
I’ll rename it.

ABataev updated this revision to Diff 394834.Dec 16 2021, 5:29 AM

Renamed lambda.

vporpo accepted this revision.Dec 16 2021, 9:43 AM

LGTM

This revision is now accepted and ready to land.Dec 16 2021, 9:43 AM
This revision was landed with ongoing or failed builds.Dec 16 2021, 11:10 AM
This revision was automatically updated to reflect the committed changes.