1*9880d681SAndroid Build Coastguard Worker; RUN: llc -march=arm64 -o - %s | FileCheck %s 2*9880d681SAndroid Build Coastguard Worker 3*9880d681SAndroid Build Coastguard Worker; ARM64ISelLowering.cpp was creating a new (floating-point) load for efficiency 4*9880d681SAndroid Build Coastguard Worker; but not updating chain-successors of the old one. As a result, the two memory 5*9880d681SAndroid Build Coastguard Worker; operations in this function both ended up direct successors to the EntryToken 6*9880d681SAndroid Build Coastguard Worker; and could be reordered. 7*9880d681SAndroid Build Coastguard Worker 8*9880d681SAndroid Build Coastguard Worker@var = global i32 0, align 4 9*9880d681SAndroid Build Coastguard Worker 10*9880d681SAndroid Build Coastguard Workerdefine float @foo() { 11*9880d681SAndroid Build Coastguard Worker; CHECK-LABEL: foo: 12*9880d681SAndroid Build Coastguard Worker ; Load must come before we clobber @var 13*9880d681SAndroid Build Coastguard Worker; CHECK: adrp x[[VARBASE:[0-9]+]], {{_?var}} 14*9880d681SAndroid Build Coastguard Worker; CHECK: ldr [[SREG:s[0-9]+]], [x[[VARBASE]], 15*9880d681SAndroid Build Coastguard Worker; CHECK: str wzr, [x[[VARBASE]], 16*9880d681SAndroid Build Coastguard Worker 17*9880d681SAndroid Build Coastguard Worker %val = load i32, i32* @var, align 4 18*9880d681SAndroid Build Coastguard Worker store i32 0, i32* @var, align 4 19*9880d681SAndroid Build Coastguard Worker 20*9880d681SAndroid Build Coastguard Worker %fltval = sitofp i32 %val to float 21*9880d681SAndroid Build Coastguard Worker ret float %fltval 22*9880d681SAndroid Build Coastguard Worker} 23