Poor code generated for whole-vector shifts

[llvmbot]

Bugzilla Link	10037
Resolution	WONTFIX
Resolved on	May 31, 2011 11:09
Version	2.9
OS	Linux
Reporter	LLVM Bugzilla Contributor
CC	@sunfishcode

Extended Description

Consider this:

define <4 x i32> @​lshr(<4 x i32> %x) {
%a = bitcast <4 x i32> %x to i128
%b = lshr i128 %a, 32
%c = bitcast i128 %b to <4 x i32>
ret <4 x i32> %c
}

it codegens to:

    movd    %xmm0, %rcx
    pextrq  $1, %xmm0, %rax
    shrdq   $32, %rax, %rcx
    movd    %rcx, %xmm0
    shrq    $32, %rax
    movd    %rax, %xmm1
    punpcklqdq      %xmm1, %xmm0    # xmm0 = xmm0[0],xmm1[0]

however it could codegen to a simple
psrldq
since the shift is by a multiple of 8.

The best way to solve this might be to turn this construct into a shufflevector
at the IR level.

[sunfishcode]

Is anyone actually writing code like this, or is this a synthetic testcase? Arguably, people writing vector code should use vector operations. Relying on the optimizer to rescue code like this will still produce disappointing results when the lshr gets CSE'd and acquires multiple uses, for example.

[llvmbot]

This comes from the gcc tree vectorizer: it generates a "vec_rshift_expr" which
I turned into this LLVM IR in dragonegg. I'd rather use generic IR if possible
rather than outputting an x86 intrinsic.

[sunfishcode]

This comes from the gcc tree vectorizer: it generates a "vec_rshift_expr" which
I turned into this LLVM IR in dragonegg. I'd rather use generic IR if possible
rather than outputting an x86 intrinsic.

A whole-vector shift intrinsic in LLVM would be justified for this. That's more work to implement than a quick instcombine hack though, of course.

[llvmbot]

I think I'm going to reimplement the GCC whole-vector shifts as vector shuffles.

[llvmbot]

(Since currently GCC only performs shifts that are a multiple of the element
bitwidth; even better, it looks like nothing is specified for the shifted in
values, i.e. they are "undef", which allows a slightly better implementation).

[lattner]

instcombining this into a shufflevector would make sense to me.

[llvmbot]

The dragonegg frontend no longer produces this construct. Instead it directly
produces a vector shuffle.