[InstCombine] eliminate bitcasts around bitwise logic ops when one input type and output type match

[rotateright]

Bugzilla Link	27925
Version	trunk
OS	All
CC	@efriedma-quic,@hfinkel,@RKSimon

Extended Description

define <4 x i32> @​bitcasts(<4 x i32> %a, <8 x i16> %b) {
%bc1 = bitcast <4 x i32> %a to <2 x i64>
%bc2 = bitcast <8 x i16> %b to <2 x i64>
%and = and <2 x i64> %bc2, %bc1
%bc3 = bitcast <2 x i64> %and to <4 x i32>
ret <4 x i32> %bc3
}

By transforming the 'and' to <4 x i32> type, we eliminate 2 bitcasts:

define <4 x i32> @​bitcasts(<4 x i32> %a, <8 x i16> %b) {
%bc2 = bitcast <8 x i16> %b to <4 x i32>
%and = and <4 x i32> %a, %bc2
ret <4 x i32> %and
}

Should this be limited to vector types?

[rotateright]

This example is derived from the discussion in:
http://reviews.llvm.org/D20774

As the motivating example there shows, x86 code based on SSE intrinsics seems to be littered with bitcasts. I was hoping there's some target-independent way to reduce that mess, but it looks like most of the transforms needed to optimize that will be target-dependent.

[efriedma-quic]

The proposed transformation is legal... and it's probably a good idea in most cases. That said, you'd want to be cautious with it if the target doesn't have free bitcasts between the types in question.

[rotateright]

Patch posted for review:
https://reviews.llvm.org/D26641

[rotateright]

The example in the bug description is optimized after:
https://reviews.llvm.org/rL287707

But cases with scalar types are still not handled. We need to make sure the backend can reverse those transforms if it would harm codegen.

define i64 @​bitcast_or_bitcast(i64 %a, <2 x i32> %b) {
%bc1 = bitcast i64 %a to <2 x i32>
%or = or <2 x i32> %bc1, %b
%bc2 = bitcast <2 x i32> %or to i64
ret i64 %bc2
}

define <2 x i32> @​bitcast_xor_bitcast(<2 x i32> %a, i64 %b) {
%bc1 = bitcast <2 x i32> %a to i64
%xor = xor i64 %bc1, %b
%bc2 = bitcast i64 %xor to <2 x i32>
ret <2 x i32> %bc2
}