2015-11-24 05:33:58 +08:00
|
|
|
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
|
2015-10-22 01:24:00 +08:00
|
|
|
; RUN: llc < %s -mtriple=x86_64-unknown-unknown | FileCheck %s
|
|
|
|
|
|
|
|
; InstCombine and DAGCombiner transform an 'add' into an 'or'
|
|
|
|
; if there are no common bits from the incoming operands.
|
|
|
|
; LEA instruction selection should be able to see through that
|
|
|
|
; transform and reduce add/shift/or instruction counts.
|
|
|
|
|
|
|
|
define i32 @or_shift1_and1(i32 %x, i32 %y) {
|
|
|
|
; CHECK-LABEL: or_shift1_and1:
|
|
|
|
; CHECK: # BB#0:
|
2016-07-09 08:19:07 +08:00
|
|
|
; CHECK-NEXT: # kill: %ESI<def> %ESI<kill> %RSI<def>
|
|
|
|
; CHECK-NEXT: # kill: %EDI<def> %EDI<kill> %RDI<def>
|
2015-10-22 01:24:00 +08:00
|
|
|
; CHECK-NEXT: andl $1, %esi
|
[x86] try harder to match bitwise 'or' into an LEA
The motivation for this patch starts with the epic fail example in PR18007:
https://llvm.org/bugs/show_bug.cgi?id=18007
...unfortunately, this patch makes no difference for that case, but it solves some
simpler cases. We'll get there some day. :)
The current 'or' matching code was using computeKnownBits() via
isBaseWithConstantOffset() -> MaskedValueIsZero(), but that's an unnecessarily limited use.
We can do more by copying the logic in ValueTracking's haveNoCommonBitsSet(), so we can
treat the 'or' as if it was an 'add'.
There's a TODO comment here because we should lift the bit-checking logic into a helper
function, so it's not duplicated in DAGCombiner.
An example of the better LEA matching:
leal (%rdi,%rdi), %eax
andl $1, %esi
orl %esi, %eax
Becomes:
andl $1, %esi
leal (%rsi,%rdi,2), %eax
Differential Revision: http://reviews.llvm.org/D13956
llvm-svn: 252515
2015-11-10 05:16:49 +08:00
|
|
|
; CHECK-NEXT: leal (%rsi,%rdi,2), %eax
|
2015-10-22 01:24:00 +08:00
|
|
|
; CHECK-NEXT: retq
|
|
|
|
|
|
|
|
%shl = shl i32 %x, 1
|
|
|
|
%and = and i32 %y, 1
|
|
|
|
%or = or i32 %and, %shl
|
|
|
|
ret i32 %or
|
|
|
|
}
|
|
|
|
|
|
|
|
define i32 @or_shift1_and1_swapped(i32 %x, i32 %y) {
|
|
|
|
; CHECK-LABEL: or_shift1_and1_swapped:
|
|
|
|
; CHECK: # BB#0:
|
2016-07-09 08:19:07 +08:00
|
|
|
; CHECK-NEXT: # kill: %ESI<def> %ESI<kill> %RSI<def>
|
|
|
|
; CHECK-NEXT: # kill: %EDI<def> %EDI<kill> %RDI<def>
|
2015-10-22 01:24:00 +08:00
|
|
|
; CHECK-NEXT: andl $1, %esi
|
[x86] try harder to match bitwise 'or' into an LEA
The motivation for this patch starts with the epic fail example in PR18007:
https://llvm.org/bugs/show_bug.cgi?id=18007
...unfortunately, this patch makes no difference for that case, but it solves some
simpler cases. We'll get there some day. :)
The current 'or' matching code was using computeKnownBits() via
isBaseWithConstantOffset() -> MaskedValueIsZero(), but that's an unnecessarily limited use.
We can do more by copying the logic in ValueTracking's haveNoCommonBitsSet(), so we can
treat the 'or' as if it was an 'add'.
There's a TODO comment here because we should lift the bit-checking logic into a helper
function, so it's not duplicated in DAGCombiner.
An example of the better LEA matching:
leal (%rdi,%rdi), %eax
andl $1, %esi
orl %esi, %eax
Becomes:
andl $1, %esi
leal (%rsi,%rdi,2), %eax
Differential Revision: http://reviews.llvm.org/D13956
llvm-svn: 252515
2015-11-10 05:16:49 +08:00
|
|
|
; CHECK-NEXT: leal (%rsi,%rdi,2), %eax
|
2015-10-22 01:24:00 +08:00
|
|
|
; CHECK-NEXT: retq
|
|
|
|
|
|
|
|
%shl = shl i32 %x, 1
|
|
|
|
%and = and i32 %y, 1
|
|
|
|
%or = or i32 %shl, %and
|
|
|
|
ret i32 %or
|
|
|
|
}
|
|
|
|
|
|
|
|
define i32 @or_shift2_and1(i32 %x, i32 %y) {
|
|
|
|
; CHECK-LABEL: or_shift2_and1:
|
|
|
|
; CHECK: # BB#0:
|
2016-07-09 08:19:07 +08:00
|
|
|
; CHECK-NEXT: # kill: %ESI<def> %ESI<kill> %RSI<def>
|
|
|
|
; CHECK-NEXT: # kill: %EDI<def> %EDI<kill> %RDI<def>
|
2015-10-22 01:24:00 +08:00
|
|
|
; CHECK-NEXT: andl $1, %esi
|
[x86] try harder to match bitwise 'or' into an LEA
The motivation for this patch starts with the epic fail example in PR18007:
https://llvm.org/bugs/show_bug.cgi?id=18007
...unfortunately, this patch makes no difference for that case, but it solves some
simpler cases. We'll get there some day. :)
The current 'or' matching code was using computeKnownBits() via
isBaseWithConstantOffset() -> MaskedValueIsZero(), but that's an unnecessarily limited use.
We can do more by copying the logic in ValueTracking's haveNoCommonBitsSet(), so we can
treat the 'or' as if it was an 'add'.
There's a TODO comment here because we should lift the bit-checking logic into a helper
function, so it's not duplicated in DAGCombiner.
An example of the better LEA matching:
leal (%rdi,%rdi), %eax
andl $1, %esi
orl %esi, %eax
Becomes:
andl $1, %esi
leal (%rsi,%rdi,2), %eax
Differential Revision: http://reviews.llvm.org/D13956
llvm-svn: 252515
2015-11-10 05:16:49 +08:00
|
|
|
; CHECK-NEXT: leal (%rsi,%rdi,4), %eax
|
2015-10-22 01:24:00 +08:00
|
|
|
; CHECK-NEXT: retq
|
|
|
|
|
|
|
|
%shl = shl i32 %x, 2
|
|
|
|
%and = and i32 %y, 1
|
|
|
|
%or = or i32 %shl, %and
|
|
|
|
ret i32 %or
|
|
|
|
}
|
|
|
|
|
|
|
|
define i32 @or_shift3_and1(i32 %x, i32 %y) {
|
|
|
|
; CHECK-LABEL: or_shift3_and1:
|
|
|
|
; CHECK: # BB#0:
|
2016-07-09 08:19:07 +08:00
|
|
|
; CHECK-NEXT: # kill: %ESI<def> %ESI<kill> %RSI<def>
|
|
|
|
; CHECK-NEXT: # kill: %EDI<def> %EDI<kill> %RDI<def>
|
2015-10-22 01:24:00 +08:00
|
|
|
; CHECK-NEXT: andl $1, %esi
|
[x86] try harder to match bitwise 'or' into an LEA
The motivation for this patch starts with the epic fail example in PR18007:
https://llvm.org/bugs/show_bug.cgi?id=18007
...unfortunately, this patch makes no difference for that case, but it solves some
simpler cases. We'll get there some day. :)
The current 'or' matching code was using computeKnownBits() via
isBaseWithConstantOffset() -> MaskedValueIsZero(), but that's an unnecessarily limited use.
We can do more by copying the logic in ValueTracking's haveNoCommonBitsSet(), so we can
treat the 'or' as if it was an 'add'.
There's a TODO comment here because we should lift the bit-checking logic into a helper
function, so it's not duplicated in DAGCombiner.
An example of the better LEA matching:
leal (%rdi,%rdi), %eax
andl $1, %esi
orl %esi, %eax
Becomes:
andl $1, %esi
leal (%rsi,%rdi,2), %eax
Differential Revision: http://reviews.llvm.org/D13956
llvm-svn: 252515
2015-11-10 05:16:49 +08:00
|
|
|
; CHECK-NEXT: leal (%rsi,%rdi,8), %eax
|
2015-10-22 01:24:00 +08:00
|
|
|
; CHECK-NEXT: retq
|
|
|
|
|
|
|
|
%shl = shl i32 %x, 3
|
|
|
|
%and = and i32 %y, 1
|
|
|
|
%or = or i32 %shl, %and
|
|
|
|
ret i32 %or
|
|
|
|
}
|
|
|
|
|
|
|
|
define i32 @or_shift3_and7(i32 %x, i32 %y) {
|
|
|
|
; CHECK-LABEL: or_shift3_and7:
|
|
|
|
; CHECK: # BB#0:
|
2016-07-09 08:19:07 +08:00
|
|
|
; CHECK-NEXT: # kill: %ESI<def> %ESI<kill> %RSI<def>
|
|
|
|
; CHECK-NEXT: # kill: %EDI<def> %EDI<kill> %RDI<def>
|
2015-10-22 01:24:00 +08:00
|
|
|
; CHECK-NEXT: andl $7, %esi
|
[x86] try harder to match bitwise 'or' into an LEA
The motivation for this patch starts with the epic fail example in PR18007:
https://llvm.org/bugs/show_bug.cgi?id=18007
...unfortunately, this patch makes no difference for that case, but it solves some
simpler cases. We'll get there some day. :)
The current 'or' matching code was using computeKnownBits() via
isBaseWithConstantOffset() -> MaskedValueIsZero(), but that's an unnecessarily limited use.
We can do more by copying the logic in ValueTracking's haveNoCommonBitsSet(), so we can
treat the 'or' as if it was an 'add'.
There's a TODO comment here because we should lift the bit-checking logic into a helper
function, so it's not duplicated in DAGCombiner.
An example of the better LEA matching:
leal (%rdi,%rdi), %eax
andl $1, %esi
orl %esi, %eax
Becomes:
andl $1, %esi
leal (%rsi,%rdi,2), %eax
Differential Revision: http://reviews.llvm.org/D13956
llvm-svn: 252515
2015-11-10 05:16:49 +08:00
|
|
|
; CHECK-NEXT: leal (%rsi,%rdi,8), %eax
|
2015-10-22 01:24:00 +08:00
|
|
|
; CHECK-NEXT: retq
|
|
|
|
|
|
|
|
%shl = shl i32 %x, 3
|
|
|
|
%and = and i32 %y, 7
|
|
|
|
%or = or i32 %shl, %and
|
|
|
|
ret i32 %or
|
|
|
|
}
|
|
|
|
|
|
|
|
; The shift is too big for an LEA.
|
|
|
|
|
|
|
|
define i32 @or_shift4_and1(i32 %x, i32 %y) {
|
|
|
|
; CHECK-LABEL: or_shift4_and1:
|
|
|
|
; CHECK: # BB#0:
|
2016-07-09 08:19:07 +08:00
|
|
|
; CHECK-NEXT: # kill: %ESI<def> %ESI<kill> %RSI<def>
|
|
|
|
; CHECK-NEXT: # kill: %EDI<def> %EDI<kill> %RDI<def>
|
2015-10-22 01:24:00 +08:00
|
|
|
; CHECK-NEXT: shll $4, %edi
|
|
|
|
; CHECK-NEXT: andl $1, %esi
|
|
|
|
; CHECK-NEXT: leal (%rsi,%rdi), %eax
|
|
|
|
; CHECK-NEXT: retq
|
|
|
|
|
|
|
|
%shl = shl i32 %x, 4
|
|
|
|
%and = and i32 %y, 1
|
|
|
|
%or = or i32 %shl, %and
|
|
|
|
ret i32 %or
|
|
|
|
}
|
|
|
|
|
|
|
|
; The mask is too big for the shift, so the 'or' isn't equivalent to an 'add'.
|
|
|
|
|
|
|
|
define i32 @or_shift3_and8(i32 %x, i32 %y) {
|
|
|
|
; CHECK-LABEL: or_shift3_and8:
|
|
|
|
; CHECK: # BB#0:
|
2016-07-09 08:19:07 +08:00
|
|
|
; CHECK-NEXT: # kill: %EDI<def> %EDI<kill> %RDI<def>
|
2015-10-22 01:24:00 +08:00
|
|
|
; CHECK-NEXT: leal (,%rdi,8), %eax
|
|
|
|
; CHECK-NEXT: andl $8, %esi
|
|
|
|
; CHECK-NEXT: orl %esi, %eax
|
|
|
|
; CHECK-NEXT: retq
|
|
|
|
|
|
|
|
%shl = shl i32 %x, 3
|
|
|
|
%and = and i32 %y, 8
|
|
|
|
%or = or i32 %shl, %and
|
|
|
|
ret i32 %or
|
|
|
|
}
|
|
|
|
|
|
|
|
; 64-bit operands should work too.
|
|
|
|
|
|
|
|
define i64 @or_shift1_and1_64(i64 %x, i64 %y) {
|
|
|
|
; CHECK-LABEL: or_shift1_and1_64:
|
|
|
|
; CHECK: # BB#0:
|
|
|
|
; CHECK-NEXT: andl $1, %esi
|
[x86] try harder to match bitwise 'or' into an LEA
The motivation for this patch starts with the epic fail example in PR18007:
https://llvm.org/bugs/show_bug.cgi?id=18007
...unfortunately, this patch makes no difference for that case, but it solves some
simpler cases. We'll get there some day. :)
The current 'or' matching code was using computeKnownBits() via
isBaseWithConstantOffset() -> MaskedValueIsZero(), but that's an unnecessarily limited use.
We can do more by copying the logic in ValueTracking's haveNoCommonBitsSet(), so we can
treat the 'or' as if it was an 'add'.
There's a TODO comment here because we should lift the bit-checking logic into a helper
function, so it's not duplicated in DAGCombiner.
An example of the better LEA matching:
leal (%rdi,%rdi), %eax
andl $1, %esi
orl %esi, %eax
Becomes:
andl $1, %esi
leal (%rsi,%rdi,2), %eax
Differential Revision: http://reviews.llvm.org/D13956
llvm-svn: 252515
2015-11-10 05:16:49 +08:00
|
|
|
; CHECK-NEXT: leaq (%rsi,%rdi,2), %rax
|
2015-10-22 01:24:00 +08:00
|
|
|
; CHECK-NEXT: retq
|
|
|
|
|
|
|
|
%shl = shl i64 %x, 1
|
|
|
|
%and = and i64 %y, 1
|
|
|
|
%or = or i64 %and, %shl
|
|
|
|
ret i64 %or
|
|
|
|
}
|
|
|
|
|