This is an archive of the discontinued LLVM Phabricator instance.

[SLP][NFC] Add test case exposing deficiency in finding reductions that feed buildvector sequence.
ClosedPublic

Authored by vdmitrie on Aug 23 2022, 3:05 PM.

Details

Summary

Pre-commit test to imprint current state in finding reductions feeding a buildvector sequence.

Diff Detail

Event Timeline

vdmitrie created this revision.Aug 23 2022, 3:05 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 23 2022, 3:05 PM
Herald added a subscriber: vporpo. · View Herald Transcript
vdmitrie requested review of this revision.Aug 23 2022, 3:05 PM

You can remove attributes. Can you try to reduce it to have just 2 reductions instead of expected 4?

Please try to use %names that show the opcode and lane, for example if you expect a load to be in lane 0 you can name it %ld0, if it should be in lane 1 you can name it %ld1 and so on. This shouldn't be too tedious if you manage to reduce it by half.

vdmitrie updated this revision to Diff 455035.Aug 23 2022, 6:17 PM

Reduced test by keeping only 2 out of 4 reductions.
Used more convenient naming.

Just a small note. When the problem was originally discovered it only reproduced with 4 reductions. The behavior was the following: the first time we tried to match a reduction it only matched one of four (because we do not traverse insertelement operands) and then 2 buildvector operands were vectorized with VF=2 and eventually the remaining one was matched in another iteration and we thus end up with two vectorized reductions and a chain of 2-way vectorization.
With just two reductions we would vectorize both merely with different SLP iterations so the problem would remain hidden. It only started to show up with just two reductions after https://reviews.llvm.org/D131965.

Just a small note. When the problem was originally discovered it only reproduced with 4 reductions. The behavior was the following: the first time we tried to match a reduction it only matched one of four (because we do not traverse insertelement operands) and then 2 buildvector operands were vectorized with VF=2 and eventually the remaining one was matched in another iteration and we thus end up with two vectorized reductions and a chain of 2-way vectorization.
With just two reductions we would vectorize both merely with different SLP iterations so the problem would remain hidden. It only started to show up with just two reductions after https://reviews.llvm.org/D131965.

Yep, it was expected.

This revision is now accepted and ready to land.Aug 24 2022, 5:20 AM
This revision was landed with ongoing or failed builds.Aug 24 2022, 11:14 AM
This revision was automatically updated to reflect the committed changes.