6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2024-12-19 01:34:32 +00:00
Code Issues Projects Releases Wiki Activity
8a3f50038f
llvm-6502/test/CodeGen/PowerPC/negctr.ll

84 lines
2.8 KiB
LLVM
Raw Normal View History

Fix large count and negative constant count handling in PPCCTRLoops This commit fixes an assert that would occur on loops with large constant counts (like looping for ((uint32_t) -1) iterations on PPC64). The existing code did not handle counts that it computed to be negative (asserting instead), but these can be created with valid inputs. This bug was discovered by bugpoint while I was attempting to isolate a completely different problem. Also, in writing test cases for the negative-count problem, I discovered that the ori/lsi handling was broken (there was a typo which caused the logic that was supposed to detect these pairs and extract the iteration count to always fail). This has now also been corrected (and is covered by one of the new test cases). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177295 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-18 17:40:44 +00:00
; RUN: llc < %s -mcpu=a2 | FileCheck %s
Fix a sign-extension bug in PPCCTRLoops Don't sign extend the immediate value from the OR instruction in an LIS/OR pair. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177361 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-18 23:58:28 +00:00
; RUN: llc < %s -mcpu=a2 -disable-lsr | FileCheck -check-prefix=NOLSR %s
Fix large count and negative constant count handling in PPCCTRLoops This commit fixes an assert that would occur on loops with large constant counts (like looping for ((uint32_t) -1) iterations on PPC64). The existing code did not handle counts that it computed to be negative (asserting instead), but these can be created with valid inputs. This bug was discovered by bugpoint while I was attempting to isolate a completely different problem. Also, in writing test cases for the negative-count problem, I discovered that the ori/lsi handling was broken (there was a typo which caused the logic that was supposed to detect these pairs and extract the iteration count to always fail). This has now also been corrected (and is covered by one of the new test cases). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177295 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-18 17:40:44 +00:00
target datalayout = "E-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-f128:128:128-v128:128:128-n32:64"
target triple = "powerpc64-unknown-linux-gnu"
define void @main() #0 {
entry:
br i1 undef, label %for.end, label %for.body
for.body: ; preds = %for.body, %entry
%indvars.iv = phi i64 [ %indvars.iv.next, %for.body ], [ 1, %entry ]
%indvars.iv.next = add i64 %indvars.iv, 1
%lftr.wideiv = trunc i64 %indvars.iv.next to i32
%exitcond = icmp eq i32 %lftr.wideiv, 0
br i1 %exitcond, label %for.end, label %for.body
; FIXME: We currently can't form the 32-bit unsigned trip count necessary here!
; CHECK: @main
; CHECK-NOT: bdnz
for.end: ; preds = %for.body, %entry
ret void
}
define void @main1() #0 {
entry:
br i1 undef, label %for.end, label %for.body
for.body: ; preds = %for.body, %entry
%indvars.iv = phi i64 [ %indvars.iv.next, %for.body ], [ 1, %entry ]
%indvars.iv.next = add i64 %indvars.iv, 1
%exitcond = icmp eq i64 %indvars.iv.next, 0
br i1 %exitcond, label %for.end, label %for.body
; CHECK: @main1
; CHECK: li [[REG:[0-9]+]], -1
; CHECK: mtctr [[REG]]
; CHECK: bdnz
for.end: ; preds = %for.body, %entry
ret void
}
define void @main2() #0 {
entry:
br i1 undef, label %for.end, label %for.body
for.body: ; preds = %for.body, %entry
%indvars.iv = phi i64 [ %indvars.iv.next, %for.body ], [ 1, %entry ]
%indvars.iv.next = add i64 %indvars.iv, 1
%exitcond = icmp eq i64 %indvars.iv.next, -100000
br i1 %exitcond, label %for.end, label %for.body
; CHECK: @main2
; CHECK: lis [[REG:[0-9]+]], -2
; CHECK: ori [[REG2:[0-9]+]], [[REG]], 31071
; CHECK: mtctr [[REG2]]
; CHECK: bdnz
for.end: ; preds = %for.body, %entry
ret void
}
Fix a sign-extension bug in PPCCTRLoops Don't sign extend the immediate value from the OR instruction in an LIS/OR pair. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177361 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-18 23:58:28 +00:00
define void @main3() #0 {
entry:
br i1 undef, label %for.end, label %for.body
for.body: ; preds = %for.body, %entry
%indvars.iv = phi i64 [ %indvars.iv.next, %for.body ], [ 127984, %entry ]
%indvars.iv.next = add i64 %indvars.iv, -16
%exitcond = icmp eq i64 %indvars.iv.next, -16
br i1 %exitcond, label %for.end, label %for.body
; NOLSR: @main3
; NOLSR: li [[REG:[0-9]+]], 8000
; NOLSR: mtctr [[REG]]
; NOLSR: bdnz
for.end: ; preds = %for.body, %entry
ret void
}
Fix large count and negative constant count handling in PPCCTRLoops This commit fixes an assert that would occur on loops with large constant counts (like looping for ((uint32_t) -1) iterations on PPC64). The existing code did not handle counts that it computed to be negative (asserting instead), but these can be created with valid inputs. This bug was discovered by bugpoint while I was attempting to isolate a completely different problem. Also, in writing test cases for the negative-count problem, I discovered that the ori/lsi handling was broken (there was a typo which caused the logic that was supposed to detect these pairs and extract the iteration count to always fail). This has now also been corrected (and is covered by one of the new test cases). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177295 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-18 17:40:44 +00:00
attributes #0 = { nounwind "less-precise-fpmad"="false" "no-frame-pointer-elim"="false" "no-frame-pointer-elim-non-leaf"="true" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "unsafe-fp-math"="false" "use-soft-float"="false" }
Reference in New Issue Copy Permalink