xref: /aosp_15_r20/external/llvm/test/CodeGen/ARM/2011-08-29-SchedCycle.ll (revision 9880d6810fe72a1726cb53787c6711e909410d58)
1*9880d681SAndroid Build Coastguard Worker; RUN: llc %s -mtriple=thumbv7-apple-darwin -mcpu=cortex-a8 -o -
2*9880d681SAndroid Build Coastguard Worker
3*9880d681SAndroid Build Coastguard Worker; When a i64 sub is expanded to subc + sube.
4*9880d681SAndroid Build Coastguard Worker;   libcall #1
5*9880d681SAndroid Build Coastguard Worker;      \
6*9880d681SAndroid Build Coastguard Worker;       \        subc
7*9880d681SAndroid Build Coastguard Worker;        \       /  \
8*9880d681SAndroid Build Coastguard Worker;         \     /    \
9*9880d681SAndroid Build Coastguard Worker;          \   /    libcall #2
10*9880d681SAndroid Build Coastguard Worker;           sube
11*9880d681SAndroid Build Coastguard Worker;
12*9880d681SAndroid Build Coastguard Worker; If the libcalls are not serialized (i.e. both have chains which are dag
13*9880d681SAndroid Build Coastguard Worker; entry), legalizer can serialize them in arbitrary orders. If it's
14*9880d681SAndroid Build Coastguard Worker; unlucky, it can force libcall #2 before libcall #1 in the above case.
15*9880d681SAndroid Build Coastguard Worker;
16*9880d681SAndroid Build Coastguard Worker;   subc
17*9880d681SAndroid Build Coastguard Worker;    |
18*9880d681SAndroid Build Coastguard Worker;   libcall #2
19*9880d681SAndroid Build Coastguard Worker;    |
20*9880d681SAndroid Build Coastguard Worker;   libcall #1
21*9880d681SAndroid Build Coastguard Worker;    |
22*9880d681SAndroid Build Coastguard Worker;   sube
23*9880d681SAndroid Build Coastguard Worker;
24*9880d681SAndroid Build Coastguard Worker; However since subc and sube are "glued" together, this ends up being a
25*9880d681SAndroid Build Coastguard Worker; cycle when the scheduler combine subc and sube as a single scheduling
26*9880d681SAndroid Build Coastguard Worker; unit.
27*9880d681SAndroid Build Coastguard Worker;
28*9880d681SAndroid Build Coastguard Worker; The right solution is to fix LegalizeType too chains the libcalls together.
29*9880d681SAndroid Build Coastguard Worker; However, LegalizeType is not processing nodes in order. The fix now is to
30*9880d681SAndroid Build Coastguard Worker; fix subc / sube (and addc / adde) to use physical register dependency instead.
31*9880d681SAndroid Build Coastguard Worker; rdar://10019576
32*9880d681SAndroid Build Coastguard Worker
33*9880d681SAndroid Build Coastguard Workerdefine void @t() nounwind {
34*9880d681SAndroid Build Coastguard Workerentry:
35*9880d681SAndroid Build Coastguard Worker  %tmp = load i64, i64* undef, align 4
36*9880d681SAndroid Build Coastguard Worker  %tmp5 = udiv i64 %tmp, 30
37*9880d681SAndroid Build Coastguard Worker  %tmp13 = and i64 %tmp5, 64739244643450880
38*9880d681SAndroid Build Coastguard Worker  %tmp16 = sub i64 0, %tmp13
39*9880d681SAndroid Build Coastguard Worker  %tmp19 = and i64 %tmp16, 63
40*9880d681SAndroid Build Coastguard Worker  %tmp20 = urem i64 %tmp19, 3
41*9880d681SAndroid Build Coastguard Worker  %tmp22 = and i64 %tmp16, -272346829004752
42*9880d681SAndroid Build Coastguard Worker  store i64 %tmp22, i64* undef, align 4
43*9880d681SAndroid Build Coastguard Worker  store i64 %tmp20, i64* undef, align 4
44*9880d681SAndroid Build Coastguard Worker  ret void
45*9880d681SAndroid Build Coastguard Worker}
46