2015-11-13 06:27:38 +08:00
|
|
|
; RUN: llc < %s -mtriple=x86_64-unknown-unknown | FileCheck %s
|
2007-12-14 10:13:44 +08:00
|
|
|
|
2011-12-24 19:46:10 +08:00
|
|
|
declare i8 @llvm.cttz.i8(i8, i1)
|
|
|
|
declare i16 @llvm.cttz.i16(i16, i1)
|
2011-12-24 19:26:57 +08:00
|
|
|
declare i32 @llvm.cttz.i32(i32, i1)
|
2011-12-24 19:46:10 +08:00
|
|
|
declare i64 @llvm.cttz.i64(i64, i1)
|
2011-12-24 19:26:59 +08:00
|
|
|
declare i8 @llvm.ctlz.i8(i8, i1)
|
2011-12-24 19:26:57 +08:00
|
|
|
declare i16 @llvm.ctlz.i16(i16, i1)
|
|
|
|
declare i32 @llvm.ctlz.i32(i32, i1)
|
2011-12-24 19:26:59 +08:00
|
|
|
declare i64 @llvm.ctlz.i64(i64, i1)
|
2007-12-14 10:13:44 +08:00
|
|
|
|
2011-12-24 19:46:10 +08:00
|
|
|
define i8 @cttz_i8(i8 %x) {
|
2015-11-13 06:27:38 +08:00
|
|
|
; CHECK-LABEL: cttz_i8:
|
|
|
|
; CHECK: # BB#0:
|
|
|
|
; CHECK-NEXT: movzbl %dil, %eax
|
|
|
|
; CHECK-NEXT: bsfl %eax, %eax
|
|
|
|
; CHECK-NEXT: retq
|
2011-12-24 19:46:10 +08:00
|
|
|
%tmp = call i8 @llvm.cttz.i8( i8 %x, i1 true )
|
|
|
|
ret i8 %tmp
|
|
|
|
}
|
|
|
|
|
|
|
|
define i16 @cttz_i16(i16 %x) {
|
2015-11-13 06:27:38 +08:00
|
|
|
; CHECK-LABEL: cttz_i16:
|
|
|
|
; CHECK: # BB#0:
|
|
|
|
; CHECK-NEXT: bsfw %di, %ax
|
|
|
|
; CHECK-NEXT: retq
|
2011-12-24 19:46:10 +08:00
|
|
|
%tmp = call i16 @llvm.cttz.i16( i16 %x, i1 true )
|
|
|
|
ret i16 %tmp
|
|
|
|
}
|
|
|
|
|
2011-12-24 19:26:57 +08:00
|
|
|
define i32 @cttz_i32(i32 %x) {
|
2015-11-13 06:27:38 +08:00
|
|
|
; CHECK-LABEL: cttz_i32:
|
|
|
|
; CHECK: # BB#0:
|
|
|
|
; CHECK-NEXT: bsfl %edi, %eax
|
|
|
|
; CHECK-NEXT: retq
|
2011-12-24 19:26:57 +08:00
|
|
|
%tmp = call i32 @llvm.cttz.i32( i32 %x, i1 true )
|
2011-12-20 19:19:37 +08:00
|
|
|
ret i32 %tmp
|
2007-12-14 10:13:44 +08:00
|
|
|
}
|
|
|
|
|
2011-12-24 19:46:10 +08:00
|
|
|
define i64 @cttz_i64(i64 %x) {
|
2015-11-13 06:27:38 +08:00
|
|
|
; CHECK-LABEL: cttz_i64:
|
|
|
|
; CHECK: # BB#0:
|
|
|
|
; CHECK-NEXT: bsfq %rdi, %rax
|
|
|
|
; CHECK-NEXT: retq
|
2011-12-24 19:46:10 +08:00
|
|
|
%tmp = call i64 @llvm.cttz.i64( i64 %x, i1 true )
|
|
|
|
ret i64 %tmp
|
|
|
|
}
|
|
|
|
|
2011-12-24 19:26:59 +08:00
|
|
|
define i8 @ctlz_i8(i8 %x) {
|
2015-11-13 06:27:38 +08:00
|
|
|
; CHECK-LABEL: ctlz_i8:
|
|
|
|
; CHECK: # BB#0:
|
|
|
|
; CHECK-NEXT: movzbl %dil, %eax
|
|
|
|
; CHECK-NEXT: bsrl %eax, %eax
|
|
|
|
; CHECK-NEXT: xorl $7, %eax
|
|
|
|
; CHECK-NEXT: retq
|
2011-12-24 19:26:59 +08:00
|
|
|
%tmp2 = call i8 @llvm.ctlz.i8( i8 %x, i1 true )
|
|
|
|
ret i8 %tmp2
|
|
|
|
}
|
|
|
|
|
|
|
|
define i16 @ctlz_i16(i16 %x) {
|
2015-11-13 06:27:38 +08:00
|
|
|
; CHECK-LABEL: ctlz_i16:
|
|
|
|
; CHECK: # BB#0:
|
|
|
|
; CHECK-NEXT: bsrw %di, %ax
|
|
|
|
; CHECK-NEXT: xorl $15, %eax
|
|
|
|
; CHECK-NEXT: retq
|
2011-12-24 19:26:59 +08:00
|
|
|
%tmp2 = call i16 @llvm.ctlz.i16( i16 %x, i1 true )
|
2011-12-20 19:19:37 +08:00
|
|
|
ret i16 %tmp2
|
2007-12-14 16:30:15 +08:00
|
|
|
}
|
|
|
|
|
2011-12-24 19:26:57 +08:00
|
|
|
define i32 @ctlz_i32(i32 %x) {
|
2015-11-13 06:27:38 +08:00
|
|
|
; CHECK-LABEL: ctlz_i32:
|
|
|
|
; CHECK: # BB#0:
|
|
|
|
; CHECK-NEXT: bsrl %edi, %eax
|
|
|
|
; CHECK-NEXT: xorl $31, %eax
|
|
|
|
; CHECK-NEXT: retq
|
2011-12-24 19:26:57 +08:00
|
|
|
%tmp = call i32 @llvm.ctlz.i32( i32 %x, i1 true )
|
|
|
|
ret i32 %tmp
|
|
|
|
}
|
2011-05-24 09:48:22 +08:00
|
|
|
|
2011-12-24 19:26:59 +08:00
|
|
|
define i64 @ctlz_i64(i64 %x) {
|
2015-11-13 06:27:38 +08:00
|
|
|
; CHECK-LABEL: ctlz_i64:
|
|
|
|
; CHECK: # BB#0:
|
|
|
|
; CHECK-NEXT: bsrq %rdi, %rax
|
|
|
|
; CHECK-NEXT: xorq $63, %rax
|
|
|
|
; CHECK-NEXT: retq
|
2011-12-24 19:26:59 +08:00
|
|
|
%tmp = call i64 @llvm.ctlz.i64( i64 %x, i1 true )
|
|
|
|
ret i64 %tmp
|
|
|
|
}
|
|
|
|
|
[CGP] despeculate expensive cttz/ctlz intrinsics
This is another step towards allowing SimplifyCFG to speculate harder, but then have
CGP clean things up if the target doesn't like it.
Previous patches in this series:
http://reviews.llvm.org/D12882
http://reviews.llvm.org/D13297
D13297 should catch most expensive ops, but speculation of cttz/ctlz requires special
handling because of weirdness in the intrinsic definition for handling a zero input
(that definition can probably be blamed on x86).
For example, if we have the usual speculated-by-select expensive op pattern like this:
%tobool = icmp eq i64 %A, 0
%0 = tail call i64 @llvm.cttz.i64(i64 %A, i1 true) ; is_zero_undef == true
%cond = select i1 %tobool, i64 64, i64 %0
ret i64 %cond
There's an instcombine that will turn it into:
%0 = tail call i64 @llvm.cttz.i64(i64 %A, i1 false) ; is_zero_undef == false
This CGP patch is looking for that case and despeculating it back into:
entry:
%tobool = icmp eq i64 %A, 0
br i1 %tobool, label %cond.end, label %cond.true
cond.true:
%0 = tail call i64 @llvm.cttz.i64(i64 %A, i1 true) ; is_zero_undef == true
br label %cond.end
cond.end:
%cond = phi i64 [ %0, %cond.true ], [ 64, %entry ]
ret i64 %cond
This unfortunately may lead to poorer codegen (see the changes in the existing x86 test),
but if we increase speculation in SimplifyCFG (the next step in this patch series), then
we should avoid those kinds of cases in the first place.
The need for this patch was originally mentioned here:
http://reviews.llvm.org/D7506
with follow-up here:
http://reviews.llvm.org/D7554
Differential Revision: http://reviews.llvm.org/D14630
llvm-svn: 253573
2015-11-20 00:37:10 +08:00
|
|
|
define i32 @ctlz_i32_zero_test(i32 %n) {
|
|
|
|
; Generate a test and branch to handle zero inputs because bsr/bsf are very slow.
|
|
|
|
|
|
|
|
; CHECK-LABEL: ctlz_i32_zero_test:
|
2015-11-13 06:27:38 +08:00
|
|
|
; CHECK: # BB#0:
|
[CGP] despeculate expensive cttz/ctlz intrinsics
This is another step towards allowing SimplifyCFG to speculate harder, but then have
CGP clean things up if the target doesn't like it.
Previous patches in this series:
http://reviews.llvm.org/D12882
http://reviews.llvm.org/D13297
D13297 should catch most expensive ops, but speculation of cttz/ctlz requires special
handling because of weirdness in the intrinsic definition for handling a zero input
(that definition can probably be blamed on x86).
For example, if we have the usual speculated-by-select expensive op pattern like this:
%tobool = icmp eq i64 %A, 0
%0 = tail call i64 @llvm.cttz.i64(i64 %A, i1 true) ; is_zero_undef == true
%cond = select i1 %tobool, i64 64, i64 %0
ret i64 %cond
There's an instcombine that will turn it into:
%0 = tail call i64 @llvm.cttz.i64(i64 %A, i1 false) ; is_zero_undef == false
This CGP patch is looking for that case and despeculating it back into:
entry:
%tobool = icmp eq i64 %A, 0
br i1 %tobool, label %cond.end, label %cond.true
cond.true:
%0 = tail call i64 @llvm.cttz.i64(i64 %A, i1 true) ; is_zero_undef == true
br label %cond.end
cond.end:
%cond = phi i64 [ %0, %cond.true ], [ 64, %entry ]
ret i64 %cond
This unfortunately may lead to poorer codegen (see the changes in the existing x86 test),
but if we increase speculation in SimplifyCFG (the next step in this patch series), then
we should avoid those kinds of cases in the first place.
The need for this patch was originally mentioned here:
http://reviews.llvm.org/D7506
with follow-up here:
http://reviews.llvm.org/D7554
Differential Revision: http://reviews.llvm.org/D14630
llvm-svn: 253573
2015-11-20 00:37:10 +08:00
|
|
|
; CHECK-NEXT: movl $32, %eax
|
|
|
|
; CHECK-NEXT: testl %edi, %edi
|
|
|
|
; CHECK-NEXT: je .LBB8_2
|
|
|
|
; CHECK-NEXT: # BB#1: # %cond.false
|
|
|
|
; CHECK-NEXT: bsrl %edi, %eax
|
2015-11-13 06:27:38 +08:00
|
|
|
; CHECK-NEXT: xorl $31, %eax
|
[CGP] despeculate expensive cttz/ctlz intrinsics
This is another step towards allowing SimplifyCFG to speculate harder, but then have
CGP clean things up if the target doesn't like it.
Previous patches in this series:
http://reviews.llvm.org/D12882
http://reviews.llvm.org/D13297
D13297 should catch most expensive ops, but speculation of cttz/ctlz requires special
handling because of weirdness in the intrinsic definition for handling a zero input
(that definition can probably be blamed on x86).
For example, if we have the usual speculated-by-select expensive op pattern like this:
%tobool = icmp eq i64 %A, 0
%0 = tail call i64 @llvm.cttz.i64(i64 %A, i1 true) ; is_zero_undef == true
%cond = select i1 %tobool, i64 64, i64 %0
ret i64 %cond
There's an instcombine that will turn it into:
%0 = tail call i64 @llvm.cttz.i64(i64 %A, i1 false) ; is_zero_undef == false
This CGP patch is looking for that case and despeculating it back into:
entry:
%tobool = icmp eq i64 %A, 0
br i1 %tobool, label %cond.end, label %cond.true
cond.true:
%0 = tail call i64 @llvm.cttz.i64(i64 %A, i1 true) ; is_zero_undef == true
br label %cond.end
cond.end:
%cond = phi i64 [ %0, %cond.true ], [ 64, %entry ]
ret i64 %cond
This unfortunately may lead to poorer codegen (see the changes in the existing x86 test),
but if we increase speculation in SimplifyCFG (the next step in this patch series), then
we should avoid those kinds of cases in the first place.
The need for this patch was originally mentioned here:
http://reviews.llvm.org/D7506
with follow-up here:
http://reviews.llvm.org/D7554
Differential Revision: http://reviews.llvm.org/D14630
llvm-svn: 253573
2015-11-20 00:37:10 +08:00
|
|
|
; CHECK-NEXT: .LBB8_2: # %cond.end
|
2015-11-13 06:27:38 +08:00
|
|
|
; CHECK-NEXT: retq
|
2011-12-24 19:26:57 +08:00
|
|
|
%tmp1 = call i32 @llvm.ctlz.i32(i32 %n, i1 false)
|
2011-12-20 19:19:37 +08:00
|
|
|
ret i32 %tmp1
|
|
|
|
}
|
|
|
|
|
2011-12-24 19:26:57 +08:00
|
|
|
define i32 @ctlz_i32_fold_cmov(i32 %n) {
|
[CGP] despeculate expensive cttz/ctlz intrinsics
This is another step towards allowing SimplifyCFG to speculate harder, but then have
CGP clean things up if the target doesn't like it.
Previous patches in this series:
http://reviews.llvm.org/D12882
http://reviews.llvm.org/D13297
D13297 should catch most expensive ops, but speculation of cttz/ctlz requires special
handling because of weirdness in the intrinsic definition for handling a zero input
(that definition can probably be blamed on x86).
For example, if we have the usual speculated-by-select expensive op pattern like this:
%tobool = icmp eq i64 %A, 0
%0 = tail call i64 @llvm.cttz.i64(i64 %A, i1 true) ; is_zero_undef == true
%cond = select i1 %tobool, i64 64, i64 %0
ret i64 %cond
There's an instcombine that will turn it into:
%0 = tail call i64 @llvm.cttz.i64(i64 %A, i1 false) ; is_zero_undef == false
This CGP patch is looking for that case and despeculating it back into:
entry:
%tobool = icmp eq i64 %A, 0
br i1 %tobool, label %cond.end, label %cond.true
cond.true:
%0 = tail call i64 @llvm.cttz.i64(i64 %A, i1 true) ; is_zero_undef == true
br label %cond.end
cond.end:
%cond = phi i64 [ %0, %cond.true ], [ 64, %entry ]
ret i64 %cond
This unfortunately may lead to poorer codegen (see the changes in the existing x86 test),
but if we increase speculation in SimplifyCFG (the next step in this patch series), then
we should avoid those kinds of cases in the first place.
The need for this patch was originally mentioned here:
http://reviews.llvm.org/D7506
with follow-up here:
http://reviews.llvm.org/D7554
Differential Revision: http://reviews.llvm.org/D14630
llvm-svn: 253573
2015-11-20 00:37:10 +08:00
|
|
|
; Don't generate the cmovne when the source is known non-zero (and bsr would
|
|
|
|
; not set ZF).
|
|
|
|
; rdar://9490949
|
|
|
|
; FIXME: The compare and branch are produced late in IR (by CodeGenPrepare), and
|
|
|
|
; codegen doesn't know how to delete the movl and je.
|
|
|
|
|
2015-11-13 06:27:38 +08:00
|
|
|
; CHECK-LABEL: ctlz_i32_fold_cmov:
|
|
|
|
; CHECK: # BB#0:
|
|
|
|
; CHECK-NEXT: orl $1, %edi
|
[CGP] despeculate expensive cttz/ctlz intrinsics
This is another step towards allowing SimplifyCFG to speculate harder, but then have
CGP clean things up if the target doesn't like it.
Previous patches in this series:
http://reviews.llvm.org/D12882
http://reviews.llvm.org/D13297
D13297 should catch most expensive ops, but speculation of cttz/ctlz requires special
handling because of weirdness in the intrinsic definition for handling a zero input
(that definition can probably be blamed on x86).
For example, if we have the usual speculated-by-select expensive op pattern like this:
%tobool = icmp eq i64 %A, 0
%0 = tail call i64 @llvm.cttz.i64(i64 %A, i1 true) ; is_zero_undef == true
%cond = select i1 %tobool, i64 64, i64 %0
ret i64 %cond
There's an instcombine that will turn it into:
%0 = tail call i64 @llvm.cttz.i64(i64 %A, i1 false) ; is_zero_undef == false
This CGP patch is looking for that case and despeculating it back into:
entry:
%tobool = icmp eq i64 %A, 0
br i1 %tobool, label %cond.end, label %cond.true
cond.true:
%0 = tail call i64 @llvm.cttz.i64(i64 %A, i1 true) ; is_zero_undef == true
br label %cond.end
cond.end:
%cond = phi i64 [ %0, %cond.true ], [ 64, %entry ]
ret i64 %cond
This unfortunately may lead to poorer codegen (see the changes in the existing x86 test),
but if we increase speculation in SimplifyCFG (the next step in this patch series), then
we should avoid those kinds of cases in the first place.
The need for this patch was originally mentioned here:
http://reviews.llvm.org/D7506
with follow-up here:
http://reviews.llvm.org/D7554
Differential Revision: http://reviews.llvm.org/D14630
llvm-svn: 253573
2015-11-20 00:37:10 +08:00
|
|
|
; CHECK-NEXT: movl $32, %eax
|
|
|
|
; CHECK-NEXT: je .LBB9_2
|
|
|
|
; CHECK-NEXT: # BB#1: # %cond.false
|
2015-11-13 06:27:38 +08:00
|
|
|
; CHECK-NEXT: bsrl %edi, %eax
|
|
|
|
; CHECK-NEXT: xorl $31, %eax
|
[CGP] despeculate expensive cttz/ctlz intrinsics
This is another step towards allowing SimplifyCFG to speculate harder, but then have
CGP clean things up if the target doesn't like it.
Previous patches in this series:
http://reviews.llvm.org/D12882
http://reviews.llvm.org/D13297
D13297 should catch most expensive ops, but speculation of cttz/ctlz requires special
handling because of weirdness in the intrinsic definition for handling a zero input
(that definition can probably be blamed on x86).
For example, if we have the usual speculated-by-select expensive op pattern like this:
%tobool = icmp eq i64 %A, 0
%0 = tail call i64 @llvm.cttz.i64(i64 %A, i1 true) ; is_zero_undef == true
%cond = select i1 %tobool, i64 64, i64 %0
ret i64 %cond
There's an instcombine that will turn it into:
%0 = tail call i64 @llvm.cttz.i64(i64 %A, i1 false) ; is_zero_undef == false
This CGP patch is looking for that case and despeculating it back into:
entry:
%tobool = icmp eq i64 %A, 0
br i1 %tobool, label %cond.end, label %cond.true
cond.true:
%0 = tail call i64 @llvm.cttz.i64(i64 %A, i1 true) ; is_zero_undef == true
br label %cond.end
cond.end:
%cond = phi i64 [ %0, %cond.true ], [ 64, %entry ]
ret i64 %cond
This unfortunately may lead to poorer codegen (see the changes in the existing x86 test),
but if we increase speculation in SimplifyCFG (the next step in this patch series), then
we should avoid those kinds of cases in the first place.
The need for this patch was originally mentioned here:
http://reviews.llvm.org/D7506
with follow-up here:
http://reviews.llvm.org/D7554
Differential Revision: http://reviews.llvm.org/D14630
llvm-svn: 253573
2015-11-20 00:37:10 +08:00
|
|
|
; CHECK-NEXT: .LBB9_2: # %cond.end
|
2015-11-13 06:27:38 +08:00
|
|
|
; CHECK-NEXT: retq
|
2011-05-24 09:48:22 +08:00
|
|
|
%or = or i32 %n, 1
|
2011-12-24 19:26:57 +08:00
|
|
|
%tmp1 = call i32 @llvm.ctlz.i32(i32 %or, i1 false)
|
2011-05-24 09:48:22 +08:00
|
|
|
ret i32 %tmp1
|
|
|
|
}
|
2011-12-24 18:55:54 +08:00
|
|
|
|
2011-12-24 19:26:57 +08:00
|
|
|
define i32 @ctlz_bsr(i32 %n) {
|
[CGP] despeculate expensive cttz/ctlz intrinsics
This is another step towards allowing SimplifyCFG to speculate harder, but then have
CGP clean things up if the target doesn't like it.
Previous patches in this series:
http://reviews.llvm.org/D12882
http://reviews.llvm.org/D13297
D13297 should catch most expensive ops, but speculation of cttz/ctlz requires special
handling because of weirdness in the intrinsic definition for handling a zero input
(that definition can probably be blamed on x86).
For example, if we have the usual speculated-by-select expensive op pattern like this:
%tobool = icmp eq i64 %A, 0
%0 = tail call i64 @llvm.cttz.i64(i64 %A, i1 true) ; is_zero_undef == true
%cond = select i1 %tobool, i64 64, i64 %0
ret i64 %cond
There's an instcombine that will turn it into:
%0 = tail call i64 @llvm.cttz.i64(i64 %A, i1 false) ; is_zero_undef == false
This CGP patch is looking for that case and despeculating it back into:
entry:
%tobool = icmp eq i64 %A, 0
br i1 %tobool, label %cond.end, label %cond.true
cond.true:
%0 = tail call i64 @llvm.cttz.i64(i64 %A, i1 true) ; is_zero_undef == true
br label %cond.end
cond.end:
%cond = phi i64 [ %0, %cond.true ], [ 64, %entry ]
ret i64 %cond
This unfortunately may lead to poorer codegen (see the changes in the existing x86 test),
but if we increase speculation in SimplifyCFG (the next step in this patch series), then
we should avoid those kinds of cases in the first place.
The need for this patch was originally mentioned here:
http://reviews.llvm.org/D7506
with follow-up here:
http://reviews.llvm.org/D7554
Differential Revision: http://reviews.llvm.org/D14630
llvm-svn: 253573
2015-11-20 00:37:10 +08:00
|
|
|
; Don't generate any xors when a 'ctlz' intrinsic is actually used to compute
|
|
|
|
; the most significant bit, which is what 'bsr' does natively.
|
|
|
|
|
2015-11-13 06:27:38 +08:00
|
|
|
; CHECK-LABEL: ctlz_bsr:
|
|
|
|
; CHECK: # BB#0:
|
|
|
|
; CHECK-NEXT: bsrl %edi, %eax
|
|
|
|
; CHECK-NEXT: retq
|
2011-12-24 19:26:57 +08:00
|
|
|
%ctlz = call i32 @llvm.ctlz.i32(i32 %n, i1 true)
|
2011-12-24 18:55:54 +08:00
|
|
|
%bsr = xor i32 %ctlz, 31
|
|
|
|
ret i32 %bsr
|
|
|
|
}
|
|
|
|
|
[CGP] despeculate expensive cttz/ctlz intrinsics
This is another step towards allowing SimplifyCFG to speculate harder, but then have
CGP clean things up if the target doesn't like it.
Previous patches in this series:
http://reviews.llvm.org/D12882
http://reviews.llvm.org/D13297
D13297 should catch most expensive ops, but speculation of cttz/ctlz requires special
handling because of weirdness in the intrinsic definition for handling a zero input
(that definition can probably be blamed on x86).
For example, if we have the usual speculated-by-select expensive op pattern like this:
%tobool = icmp eq i64 %A, 0
%0 = tail call i64 @llvm.cttz.i64(i64 %A, i1 true) ; is_zero_undef == true
%cond = select i1 %tobool, i64 64, i64 %0
ret i64 %cond
There's an instcombine that will turn it into:
%0 = tail call i64 @llvm.cttz.i64(i64 %A, i1 false) ; is_zero_undef == false
This CGP patch is looking for that case and despeculating it back into:
entry:
%tobool = icmp eq i64 %A, 0
br i1 %tobool, label %cond.end, label %cond.true
cond.true:
%0 = tail call i64 @llvm.cttz.i64(i64 %A, i1 true) ; is_zero_undef == true
br label %cond.end
cond.end:
%cond = phi i64 [ %0, %cond.true ], [ 64, %entry ]
ret i64 %cond
This unfortunately may lead to poorer codegen (see the changes in the existing x86 test),
but if we increase speculation in SimplifyCFG (the next step in this patch series), then
we should avoid those kinds of cases in the first place.
The need for this patch was originally mentioned here:
http://reviews.llvm.org/D7506
with follow-up here:
http://reviews.llvm.org/D7554
Differential Revision: http://reviews.llvm.org/D14630
llvm-svn: 253573
2015-11-20 00:37:10 +08:00
|
|
|
define i32 @ctlz_bsr_zero_test(i32 %n) {
|
|
|
|
; Generate a test and branch to handle zero inputs because bsr/bsf are very slow.
|
|
|
|
; FIXME: The compare and branch are produced late in IR (by CodeGenPrepare), and
|
|
|
|
; codegen doesn't know how to combine the $32 and $31 into $63.
|
|
|
|
|
|
|
|
; CHECK-LABEL: ctlz_bsr_zero_test:
|
2015-11-13 06:27:38 +08:00
|
|
|
; CHECK: # BB#0:
|
[CGP] despeculate expensive cttz/ctlz intrinsics
This is another step towards allowing SimplifyCFG to speculate harder, but then have
CGP clean things up if the target doesn't like it.
Previous patches in this series:
http://reviews.llvm.org/D12882
http://reviews.llvm.org/D13297
D13297 should catch most expensive ops, but speculation of cttz/ctlz requires special
handling because of weirdness in the intrinsic definition for handling a zero input
(that definition can probably be blamed on x86).
For example, if we have the usual speculated-by-select expensive op pattern like this:
%tobool = icmp eq i64 %A, 0
%0 = tail call i64 @llvm.cttz.i64(i64 %A, i1 true) ; is_zero_undef == true
%cond = select i1 %tobool, i64 64, i64 %0
ret i64 %cond
There's an instcombine that will turn it into:
%0 = tail call i64 @llvm.cttz.i64(i64 %A, i1 false) ; is_zero_undef == false
This CGP patch is looking for that case and despeculating it back into:
entry:
%tobool = icmp eq i64 %A, 0
br i1 %tobool, label %cond.end, label %cond.true
cond.true:
%0 = tail call i64 @llvm.cttz.i64(i64 %A, i1 true) ; is_zero_undef == true
br label %cond.end
cond.end:
%cond = phi i64 [ %0, %cond.true ], [ 64, %entry ]
ret i64 %cond
This unfortunately may lead to poorer codegen (see the changes in the existing x86 test),
but if we increase speculation in SimplifyCFG (the next step in this patch series), then
we should avoid those kinds of cases in the first place.
The need for this patch was originally mentioned here:
http://reviews.llvm.org/D7506
with follow-up here:
http://reviews.llvm.org/D7554
Differential Revision: http://reviews.llvm.org/D14630
llvm-svn: 253573
2015-11-20 00:37:10 +08:00
|
|
|
; CHECK-NEXT: movl $32, %eax
|
|
|
|
; CHECK-NEXT: testl %edi, %edi
|
|
|
|
; CHECK-NEXT: je .LBB11_2
|
|
|
|
; CHECK-NEXT: # BB#1: # %cond.false
|
|
|
|
; CHECK-NEXT: bsrl %edi, %eax
|
|
|
|
; CHECK-NEXT: xorl $31, %eax
|
|
|
|
; CHECK-NEXT: .LBB11_2: # %cond.end
|
|
|
|
; CHECK-NEXT: xorl $31, %eax
|
2015-11-13 06:27:38 +08:00
|
|
|
; CHECK-NEXT: retq
|
2011-12-24 19:26:57 +08:00
|
|
|
%ctlz = call i32 @llvm.ctlz.i32(i32 %n, i1 false)
|
2011-12-24 18:55:54 +08:00
|
|
|
%bsr = xor i32 %ctlz, 31
|
|
|
|
ret i32 %bsr
|
|
|
|
}
|