Vendor import of llvm release_30 branch r142614:

http://llvm.org/svn/llvm-project/llvm/branches/release_30@142614

1 files changed, 45 insertions, 0 deletions

diff --git a/test/CodeGen/ARM/2011-08-29-SchedCycle.ll b/test/CodeGen/ARM/2011-08-29-SchedCycle.ll
new file mode 100644
index 0000000..be188ef
--- /dev/null
+++ b/test/CodeGen/ARM/2011-08-29-SchedCycle.ll
@@ -0,0 +1,45 @@
+; RUN: llc %s -mtriple=thumbv7-apple-darwin -mcpu=cortex-a8 -o -
+
+; When a i64 sub is expanded to subc + sube.
+;   libcall #1
+;      \
+;       \        subc 
+;        \       /  \
+;         \     /    \
+;          \   /    libcall #2
+;           sube
+;
+; If the libcalls are not serialized (i.e. both have chains which are dag
+; entry), legalizer can serialize them in arbitrary orders. If it's
+; unlucky, it can force libcall #2 before libcall #1 in the above case.
+;
+;   subc
+;    |
+;   libcall #2
+;    |
+;   libcall #1
+;    |
+;   sube
+;
+; However since subc and sube are "glued" together, this ends up being a
+; cycle when the scheduler combine subc and sube as a single scheduling
+; unit.
+;
+; The right solution is to fix LegalizeType too chains the libcalls together.
+; However, LegalizeType is not processing nodes in order. The fix now is to
+; fix subc / sube (and addc / adde) to use physical register dependency instead.
+; rdar://10019576
+
+define void @t() nounwind {
+entry:
+  %tmp = load i64* undef, align 4
+  %tmp5 = udiv i64 %tmp, 30
+  %tmp13 = and i64 %tmp5, 64739244643450880
+  %tmp16 = sub i64 0, %tmp13
+  %tmp19 = and i64 %tmp16, 63
+  %tmp20 = urem i64 %tmp19, 3
+  %tmp22 = and i64 %tmp16, -272346829004752
+  store i64 %tmp22, i64* undef, align 4
+  store i64 %tmp20, i64* undef, align 4
+  ret void
+}