maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/ARM/Windows/dbzchk.ll

145 lines
3.4 KiB
LLVM
Raw Normal View History

ARM: Revert SVN r253865, 254158, fix windows division The two changes together weakened the test and caused a regression with division handling in MSVC mode. They were applied to avoid an assertion being triggered in the block frequency analysis. However, the underlying problem was simply being masked rather than solved properly. Address the actual underlying problem and revert the changes. Rather than analyze the cause of the assertion, the division failure was assumed to be an overflow. The underlying issue was a subtle bug in the BB construction in the emission of the div-by-zero check (WIN__DBZCHK). We did not construct the proper successor information in the basic blocks, nor did we update the PHIs associated with the basic block when we split them. This would result in assertions being triggered in the block frequency analysis pass. Although the original tests are being removed, the tests themselves performed very little in terms of validation but merely tested that we did not assert when generating code. Update this with new tests that actually ensure that we do not regress on the code generation. llvm-svn: 263714
2016-03-17 22:10:49 +08:00
; RUN: llc -mtriple thumbv7--windows-itanium -print-machineinstrs=expand-isel-pseudos -o /dev/null %s 2>&1 | FileCheck %s -check-prefix CHECK-DIV
; int f(int n, int d) {
; if (n / d)
; return 1;
; return 0;
; }
define arm_aapcs_vfpcc i32 @f(i32 %n, i32 %d) {
entry:
%retval = alloca i32, align 4
%n.addr = alloca i32, align 4
%d.addr = alloca i32, align 4
store i32 %n, i32* %n.addr, align 4
store i32 %d, i32* %d.addr, align 4
%0 = load i32, i32* %n.addr, align 4
%1 = load i32, i32* %d.addr, align 4
%div = sdiv i32 %0, %1
%tobool = icmp ne i32 %div, 0
br i1 %tobool, label %if.then, label %if.end
if.then:
store i32 1, i32* %retval, align 4
br label %return
if.end:
store i32 0, i32* %retval, align 4
br label %return
return:
%2 = load i32, i32* %retval, align 4
ret i32 %2
}
; CHECK-DIV-DAG: BB#0
; CHECK-DIV-DAG: Successors according to CFG: BB#5({{.*}}) BB#4
; CHECK-DIV-DAG: BB#1
; CHECK-DIV-DAG: Successors according to CFG: BB#3
; CHECK-DIV-DAG: BB#2
; CHECK-DIV-DAG: Successors according to CFG: BB#3
; CHECK-DIV-DAG: BB#3
; CHECK-DIV-DAG: BB#4
; CHECK-DIV-DAG: Successors according to CFG: BB#1({{.*}}) BB#2
; CHECK-DIV-DAG: BB#5
; RUN: llc -mtriple thumbv7--windows-itanium -print-machineinstrs=expand-isel-pseudos -o /dev/null %s 2>&1 | FileCheck %s -check-prefix CHECK-MOD
; int r;
; int g(int l, int m) {
; if (m <= 0)
; return 0;
; return (r = l % m);
; }
@r = common global i32 0, align 4
define arm_aapcs_vfpcc i32 @g(i32 %l, i32 %m) {
entry:
%cmp = icmp eq i32 %m, 0
br i1 %cmp, label %return, label %if.end
if.end:
%rem = urem i32 %l, %m
store i32 %rem, i32* @r, align 4
br label %return
return:
%retval.0 = phi i32 [ %rem, %if.end ], [ 0, %entry ]
ret i32 %retval.0
}
; CHECK-MOD-DAG: BB#0
; CHECK-MOD-DAG: Successors according to CFG: BB#2({{.*}}) BB#1
; CHECK-MOD-DAG: BB#1
; CHECK-MOD-DAG: Successors according to CFG: BB#4({{.*}}) BB#3
; CHECK-MOD-DAG: BB#2
; CHECK-MOD-DAG: BB#3
; CHECK-MOD-DAG: Successors according to CFG: BB#2
; CHECK-MOD-DAG: BB#4
ARM: maintain BB ordering when expanding WIN__DBZCHK It is possible to have a fallthrough MBB prior to MBB placement. The original addition of the BB would result in reordering the BB as not preceding the successor. Because of the fallthrough nature of the BB, we could end up executing incorrect code or even a constant pool island! Insert the spliced BB into the same location to avoid that. Thanks to Tim Northover for invaluable hints and Fiora for the discussion on what may have been occurring! llvm-svn: 264454
2016-03-26 03:48:06 +08:00
; RUN: llc -mtriple thumbv7--windows-itanium -print-machineinstrs=expand-isel-pseudos -filetype asm -o - %s 2>&1 | FileCheck %s -check-prefix CHECK-CFG
; unsigned c;
; extern unsigned long g(void);
; int f(unsigned u, signed char b) {
; if (b)
; c = g() % u;
; return c;
; }
@c = common global i32 0, align 4
declare arm_aapcs_vfpcc i32 @i()
define arm_aapcs_vfpcc i32 @h(i32 %u, i8 signext %b) #0 {
entry:
%tobool = icmp eq i8 %b, 0
br i1 %tobool, label %entry.if.end_crit_edge, label %if.then
entry.if.end_crit_edge:
%.pre = load i32, i32* @c, align 4
br label %if.end
if.then:
%call = tail call arm_aapcs_vfpcc i32 @i()
%rem = urem i32 %call, %u
store i32 %rem, i32* @c, align 4
br label %if.end
if.end:
%0 = phi i32 [ %.pre, %entry.if.end_crit_edge ], [ %rem, %if.then ]
ret i32 %0
}
attributes #0 = { optsize }
; CHECK-CFG-DAG: BB#0
fix checks: *_DAG -> *-DAG llvm-svn: 264676
2016-03-29 06:11:06 +08:00
; CHECK-CFG-DAG: t2Bcc <BB#2>
ARM: maintain BB ordering when expanding WIN__DBZCHK It is possible to have a fallthrough MBB prior to MBB placement. The original addition of the BB would result in reordering the BB as not preceding the successor. Because of the fallthrough nature of the BB, we could end up executing incorrect code or even a constant pool island! Insert the spliced BB into the same location to avoid that. Thanks to Tim Northover for invaluable hints and Fiora for the discussion on what may have been occurring! llvm-svn: 264454
2016-03-26 03:48:06 +08:00
; CHECK-CFG-DAG: t2B <BB#1>
; CHECK-CFG-DAG: BB#1
; CHECK-CFG-DAG: t2B <BB#3>
; CHECK-CFG-DAG: BB#2
; CHECK-CFG-DAG: tCBZ %vreg{{[0-9]}}, <BB#5>
; CHECK-CFG-DAG: t2B <BB#4>
; CHECK-CFG-DAG: BB#4
; CHECK-CFG-DAG: BB#3
; CHECK-CFG-DAG: tBX_RET
; CHECK-CFG-DAG: BB#5
; CHECK-CFG-DAG: t2UDF 249
; CHECK-CFG-LABEL: h:
; CHECK-CFG: cbz r{{[0-9]}}, .LBB2_2
; CHECK-CFG: b .LBB2_4
; CHECK-CFG-LABEL: .LBB2_2:
; CHECK-CFG-NEXT: udf.w #249
; CHECK-CFG-LABEL: .LBB2_4:
; CHECK-CFG: bl __rt_udiv
; CHECK-CFG: pop.w {{{.*}}, r11, pc}