llvm-project/llvm/test/Transforms/IndVarSimplify/floating-point-iv.ll

; RUN: opt < %s -indvars -S | FileCheck %s
define void @test1() nounwind {
entry:
	br label %bb

bb:		; preds = %bb, %entry
	%x.0.reg2mem.0 = phi double [ 0.000000e+00, %entry ], [ %1, %bb ]		; <double> [#uses=2]
	%0 = tail call i32 @foo(double %x.0.reg2mem.0) nounwind		; <i32> [#uses=0]
	%1 = fadd double %x.0.reg2mem.0, 1.000000e+00		; <double> [#uses=2]
	%2 = fcmp olt double %1, 1.000000e+04		; <i1> [#uses=1]
	br i1 %2, label %bb, label %return

return:		; preds = %bb
	ret void
; CHECK: @test1
; CHECK: icmp
}

declare i32 @foo(double)

define void @test2() nounwind {
entry:
	br label %bb

bb:		; preds = %bb, %entry
	%x.0.reg2mem.0 = phi double [ -10.000000e+00, %entry ], [ %1, %bb ]		; <double> [#uses=2]
	%0 = tail call i32 @foo(double %x.0.reg2mem.0) nounwind		; <i32> [#uses=0]
	%1 = fadd double %x.0.reg2mem.0, 2.000000e+00		; <double> [#uses=2]
	%2 = fcmp olt double %1, -1.000000e+00		; <i1> [#uses=1]
	br i1 %2, label %bb, label %return

return:		; preds = %bb
	ret void
; CHECK: @test2
; CHECK: icmp
}


define void @test3() nounwind {
entry:
	br label %bb

bb:		; preds = %bb, %entry
	%x.0.reg2mem.0 = phi double [ 0.000000e+00, %entry ], [ %1, %bb ]
	%0 = tail call i32 @foo(double %x.0.reg2mem.0) nounwind
	%1 = fadd double %x.0.reg2mem.0, 1.000000e+00
	%2 = fcmp olt double %1, -1.000000e+00
	br i1 %2, label %bb, label %return

return:
	ret void
; CHECK: @test3
; CHECK: fcmp
}

define void @test4() nounwind {
entry:
	br label %bb

bb:		; preds = %bb, %entry
	%x.0.reg2mem.0 = phi double [ 40.000000e+00, %entry ], [ %1, %bb ]		; <double> [#uses=2]
	%0 = tail call i32 @foo(double %x.0.reg2mem.0) nounwind		; <i32> [#uses=0]
	%1 = fadd double %x.0.reg2mem.0, -1.000000e+00		; <double> [#uses=2]
	%2 = fcmp olt double %1, 1.000000e+00		; <i1> [#uses=1]
	br i1 %2, label %bb, label %return

return:
	ret void
; CHECK: @test4
; CHECK: fcmp
}

; PR6761
define void @test5() nounwind {
; <label>:0
  br label %1

; <label>:1                                       ; preds = %1, %0
  %2 = phi double [ 9.000000e+00, %0 ], [ %4, %1 ] ; <double> [#uses=1]
  %3 = tail call i32 @foo(double 0.0)              ; <i32> [#uses=0]
  %4 = fadd double %2, -1.000000e+00              ; <double> [#uses=2]
  %5 = fcmp ult double %4, 0.000000e+00           ; <i1> [#uses=1]
  br i1 %5, label %exit, label %1

exit:
  ret void
  
; CHECK: @test5
; CHECK: icmp eq i32 {{.*}}, 10
; CHECK-NEXT: br i1
}
convert to filecheck llvm-svn: 100281 2010-04-03 14:27:56 +08:00			`; RUN: opt < %s -indvars -S \| FileCheck %s`
			`define void @test1() nounwind {`
Turn floating point IVs into integer IVs where possible. This allows SCEV users to effectively calculate trip count. LSR later on transforms back integer IVs to floating point IVs later on to avoid int-to-float casts inside the loop. llvm-svn: 58625 2008-11-04 02:32:19 +08:00			`entry:`
			`br label %bb`

			`bb: ; preds = %bb, %entry`
			`%x.0.reg2mem.0 = phi double [ 0.000000e+00, %entry ], [ %1, %bb ] ; <double> [#uses=2]`
			`%0 = tail call i32 @foo(double %x.0.reg2mem.0) nounwind ; <i32> [#uses=0]`
Split the Add, Sub, and Mul instruction opcodes into separate integer and floating-point opcodes, introducing FAdd, FSub, and FMul. For now, the AsmParser, BitcodeReader, and IRBuilder all preserve backwards compatability, and the Core LLVM APIs preserve backwards compatibility for IR producers. Most front-ends won't need to change immediately. This implements the first step of the plan outlined here: http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt llvm-svn: 72897 2009-06-05 06:49:04 +08:00			`%1 = fadd double %x.0.reg2mem.0, 1.000000e+00 ; <double> [#uses=2]`
Turn floating point IVs into integer IVs where possible. This allows SCEV users to effectively calculate trip count. LSR later on transforms back integer IVs to floating point IVs later on to avoid int-to-float casts inside the loop. llvm-svn: 58625 2008-11-04 02:32:19 +08:00			`%2 = fcmp olt double %1, 1.000000e+04 ; <i1> [#uses=1]`
			`br i1 %2, label %bb, label %return`

			`return: ; preds = %bb`
			`ret void`
convert to filecheck llvm-svn: 100281 2010-04-03 14:27:56 +08:00			`; CHECK: @test1`
			`; CHECK: icmp`
Turn floating point IVs into integer IVs where possible. This allows SCEV users to effectively calculate trip count. LSR later on transforms back integer IVs to floating point IVs later on to avoid int-to-float casts inside the loop. llvm-svn: 58625 2008-11-04 02:32:19 +08:00			`}`

			`declare i32 @foo(double)`
While handling floating point IVs lift restrictions on initial value and increment value. llvm-svn: 59471 2008-11-18 07:27:13 +08:00
convert to filecheck llvm-svn: 100281 2010-04-03 14:27:56 +08:00			`define void @test2() nounwind {`
While handling floating point IVs lift restrictions on initial value and increment value. llvm-svn: 59471 2008-11-18 07:27:13 +08:00			`entry:`
			`br label %bb`

			`bb: ; preds = %bb, %entry`
			`%x.0.reg2mem.0 = phi double [ -10.000000e+00, %entry ], [ %1, %bb ] ; <double> [#uses=2]`
			`%0 = tail call i32 @foo(double %x.0.reg2mem.0) nounwind ; <i32> [#uses=0]`
Split the Add, Sub, and Mul instruction opcodes into separate integer and floating-point opcodes, introducing FAdd, FSub, and FMul. For now, the AsmParser, BitcodeReader, and IRBuilder all preserve backwards compatability, and the Core LLVM APIs preserve backwards compatibility for IR producers. Most front-ends won't need to change immediately. This implements the first step of the plan outlined here: http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt llvm-svn: 72897 2009-06-05 06:49:04 +08:00			`%1 = fadd double %x.0.reg2mem.0, 2.000000e+00 ; <double> [#uses=2]`
While handling floating point IVs lift restrictions on initial value and increment value. llvm-svn: 59471 2008-11-18 07:27:13 +08:00			`%2 = fcmp olt double %1, -1.000000e+00 ; <i1> [#uses=1]`
			`br i1 %2, label %bb, label %return`

			`return: ; preds = %bb`
			`ret void`
convert to filecheck llvm-svn: 100281 2010-04-03 14:27:56 +08:00			`; CHECK: @test2`
			`; CHECK: icmp`
While handling floating point IVs lift restrictions on initial value and increment value. llvm-svn: 59471 2008-11-18 07:27:13 +08:00			`}`


convert to filecheck llvm-svn: 100281 2010-04-03 14:27:56 +08:00			`define void @test3() nounwind {`
While handling floating point IVs lift restrictions on initial value and increment value. llvm-svn: 59471 2008-11-18 07:27:13 +08:00			`entry:`
			`br label %bb`

			`bb: ; preds = %bb, %entry`
fix PR6761, a miscompilation due to the fp->int IV conversion stuff. More bugs remain though. llvm-svn: 100282 2010-04-03 14:30:03 +08:00			`%x.0.reg2mem.0 = phi double [ 0.000000e+00, %entry ], [ %1, %bb ]`
			`%0 = tail call i32 @foo(double %x.0.reg2mem.0) nounwind`
			`%1 = fadd double %x.0.reg2mem.0, 1.000000e+00`
			`%2 = fcmp olt double %1, -1.000000e+00`
While handling floating point IVs lift restrictions on initial value and increment value. llvm-svn: 59471 2008-11-18 07:27:13 +08:00			`br i1 %2, label %bb, label %return`

add integer overflow check for the fp induction variable checker. Amusingly, we already had tests that we should have rejects because they would be miscompiled in the testsuite. The remaining issue with this is that we don't check that the branch causes us to exit the loop if it fails, so we don't actually know if we remain in bounds. llvm-svn: 100284 2010-04-03 15:18:48 +08:00			`return:`
While handling floating point IVs lift restrictions on initial value and increment value. llvm-svn: 59471 2008-11-18 07:27:13 +08:00			`ret void`
convert to filecheck llvm-svn: 100281 2010-04-03 14:27:56 +08:00			`; CHECK: @test3`
add integer overflow check for the fp induction variable checker. Amusingly, we already had tests that we should have rejects because they would be miscompiled in the testsuite. The remaining issue with this is that we don't check that the branch causes us to exit the loop if it fails, so we don't actually know if we remain in bounds. llvm-svn: 100284 2010-04-03 15:18:48 +08:00			`; CHECK: fcmp`
While handling floating point IVs lift restrictions on initial value and increment value. llvm-svn: 59471 2008-11-18 07:27:13 +08:00			`}`

convert to filecheck llvm-svn: 100281 2010-04-03 14:27:56 +08:00			`define void @test4() nounwind {`
While handling floating point IVs lift restrictions on initial value and increment value. llvm-svn: 59471 2008-11-18 07:27:13 +08:00			`entry:`
			`br label %bb`

			`bb: ; preds = %bb, %entry`
			`%x.0.reg2mem.0 = phi double [ 40.000000e+00, %entry ], [ %1, %bb ] ; <double> [#uses=2]`
			`%0 = tail call i32 @foo(double %x.0.reg2mem.0) nounwind ; <i32> [#uses=0]`
Split the Add, Sub, and Mul instruction opcodes into separate integer and floating-point opcodes, introducing FAdd, FSub, and FMul. For now, the AsmParser, BitcodeReader, and IRBuilder all preserve backwards compatability, and the Core LLVM APIs preserve backwards compatibility for IR producers. Most front-ends won't need to change immediately. This implements the first step of the plan outlined here: http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt llvm-svn: 72897 2009-06-05 06:49:04 +08:00			`%1 = fadd double %x.0.reg2mem.0, -1.000000e+00 ; <double> [#uses=2]`
While handling floating point IVs lift restrictions on initial value and increment value. llvm-svn: 59471 2008-11-18 07:27:13 +08:00			`%2 = fcmp olt double %1, 1.000000e+00 ; <i1> [#uses=1]`
			`br i1 %2, label %bb, label %return`

add integer overflow check for the fp induction variable checker. Amusingly, we already had tests that we should have rejects because they would be miscompiled in the testsuite. The remaining issue with this is that we don't check that the branch causes us to exit the loop if it fails, so we don't actually know if we remain in bounds. llvm-svn: 100284 2010-04-03 15:18:48 +08:00			`return:`
While handling floating point IVs lift restrictions on initial value and increment value. llvm-svn: 59471 2008-11-18 07:27:13 +08:00			`ret void`
convert to filecheck llvm-svn: 100281 2010-04-03 14:27:56 +08:00			`; CHECK: @test4`
add integer overflow check for the fp induction variable checker. Amusingly, we already had tests that we should have rejects because they would be miscompiled in the testsuite. The remaining issue with this is that we don't check that the branch causes us to exit the loop if it fails, so we don't actually know if we remain in bounds. llvm-svn: 100284 2010-04-03 15:18:48 +08:00			`; CHECK: fcmp`
While handling floating point IVs lift restrictions on initial value and increment value. llvm-svn: 59471 2008-11-18 07:27:13 +08:00			`}`

fix PR6761, a miscompilation due to the fp->int IV conversion stuff. More bugs remain though. llvm-svn: 100282 2010-04-03 14:30:03 +08:00			`; PR6761`
			`define void @test5() nounwind {`
			`; <label>:0`
			`br label %1`

			`; <label>:1 ; preds = %1, %0`
			`%2 = phi double [ 9.000000e+00, %0 ], [ %4, %1 ] ; <double> [#uses=1]`
			`%3 = tail call i32 @foo(double 0.0) ; <i32> [#uses=0]`
			`%4 = fadd double %2, -1.000000e+00 ; <double> [#uses=2]`
			`%5 = fcmp ult double %4, 0.000000e+00 ; <i1> [#uses=1]`
			`br i1 %5, label %exit, label %1`

			`exit:`
			`ret void`

			`; CHECK: @test5`
			`; CHECK: icmp eq i32 {{.*}}, 10`
			`; CHECK-NEXT: br i1`
			`}`
While handling floating point IVs lift restrictions on initial value and increment value. llvm-svn: 59471 2008-11-18 07:27:13 +08:00