[SLP] Suboptimal codegen for {x, y} ↦ {x+x, x+y}

[dsprenkels]

Bugzilla Link	41456
Version	trunk
OS	Linux
CC	@topperc,@LebedevRI,@RKSimon,@rotateright,@vporpo

Extended Description

https://godbolt.org/z/2GE_vO

---

The code snippet

#include <xmmintrin.h>

__m128i example(const __m128i vec) {
    return (__m128i){2 * vec[0], vec[0] + vec[1]};
}

is compiled to code that unpacks and repacks the values to the general purpose registers. This uses 7 instructions. However, the same could easily be achieved using

example:
    vpbroadcastq xmm1, xmm0
    vpaddq xmm0, xmm0, xmm1
    ret
```.

Other instructions, instead of vpbroadcastq can also be used; like vmovddup, vpermilpd, etc.

[dsprenkels]

A more complete godbolt enviroment, as posted by @​LebedevRI on IRC: https://godbolt.org/z/Am6HqA

[LebedevRI]

A more complete godbolt enviroment, as posted by @​LebedevRI on IRC:
https://godbolt.org/z/Am6HqA

To add to that, i think this isn't fully only a back-end problem,
i'd think this splat shuffle is also special, much like vector-select,
and should be produced in middle-end?

[rotateright]

A more complete godbolt enviroment, as posted by @​LebedevRI on IRC:
https://godbolt.org/z/Am6HqA

To add to that, i think this isn't fully only a back-end problem,
i'd think this splat shuffle is also special, much like vector-select,
and should be produced in middle-end?

We should treat splat as a special kind of shuffle, but I'm not seeing how instcombine can get there without some help.

The SLP vectorizer should be able to transform this, but it's a tough problem because the 'add' got canonicalized into a shift, so SLP doesn't see the vector opportunity.

There might be another bug tracking it, but that could be seen as a variation of bug 30787.

[RKSimon]

Adding Vasileios as he might have some ideas for SLP

[llvmbot]

We could potentially handle these patterns similarly to the alternate sequences. I think it would not be too hard to implement once we have managed to hide the actual LLVM instructions from the implementation and have completely replaced the accesses to the IR instructions with accesses to TreeEntry. We already support operands in TreeEntry, and a patch is under review for fixing the scheduler too (https://reviews.llvm.org/D62432). This should allow us to switch opcodes and operands in TreeEntry, without having to modify the IR.

Overall I guess this would require changes in a couple of places, including: i) The seed selection should accept the patterns, ii) buildTree should figure out which of the alternative expression form should be used while building the tree, and iii) vectorizeTree() should handle them properly.