46 lines
1.3 KiB
LLVM
46 lines
1.3 KiB
LLVM
|
; 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, 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
|
||
|
|
}
|