9e4ab7dc86
To keep cross-compiling straightforward, Cretonne shouldn't have any behavior that depends on the host. This renames the "Native" calling convention to "SystemV", which has a defined meaning for each target, so that it's clear that the calling convention doesn't change depending on what host Cretonne is running on.
47 lines
1.3 KiB
Plaintext
47 lines
1.3 KiB
Plaintext
test regalloc
|
|
|
|
isa intel
|
|
|
|
; regex: V=v\d+
|
|
|
|
; The value v9 appears both as the branch control and one of the EBB arguments
|
|
; in the brnz instruction in ebb2. It also happens that v7 and v9 are assigned
|
|
; to the same register, so v9 doesn't need to be moved before the brnz.
|
|
;
|
|
; This ended up confusong the constraint solver which had not made a record of
|
|
; the fixed register assignment for v9 since it was already in the correct
|
|
; register.
|
|
function %pr147(i32) -> i32 system_v {
|
|
ebb0(v0: i32):
|
|
v1 = iconst.i32 0
|
|
v2 = iconst.i32 1
|
|
v3 = iconst.i32 0
|
|
jump ebb2(v3, v2, v0)
|
|
|
|
ebb2(v4: i32, v5: i32, v7: i32):
|
|
; check: ebb2
|
|
v6 = iadd v4, v5
|
|
v8 = iconst.i32 -1
|
|
; v7 is killed here and v9 gets the same register.
|
|
v9 = iadd v7, v8
|
|
; check: v9 = iadd v7, v8
|
|
; Here v9 the brnz control appears to interfere with v9 the EBB argument,
|
|
; so divert_fixed_input_conflicts() calls add_var(v9), which is ok. The
|
|
; add_var sanity checks got confused when no fixed assignment could be
|
|
; found for v9.
|
|
;
|
|
; We should be able to handle this situation without making copies of v9.
|
|
brnz v9, ebb2(v5, v6, v9)
|
|
; check: brnz v9, ebb2($V, $V, v9)
|
|
jump ebb3
|
|
|
|
ebb3:
|
|
return v5
|
|
}
|
|
|
|
function %select_i64(i64, i64, i32) -> i64 {
|
|
ebb0(v0: i64, v1: i64, v2: i32):
|
|
v3 = select v2, v0, v1
|
|
return v3
|
|
}
|