maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/ARM/atomic-cmpxchg.ll

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

100 lines
3.8 KiB
LLVM
Raw Normal View History

[ARM] Make MachineVerifier more strict about terminators Fix the ARM backend's analyzeBranch so it doesn't ignore predicated return instructions, and make the MachineVerifier rule more strict. Differential Revision: https://reviews.llvm.org/D40061
2020-08-27 14:09:25 +08:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
[ARM] Emit clrex in the expanded cmpxchg fail block. ARM counterpart to r248291: In the comparison failure block of a cmpxchg expansion, the initial ldrex/ldxr will not be followed by a matching strex/stxr. On ARM/AArch64, this unnecessarily ties up the execution monitor, which might have a negative performance impact on some uarchs. Instead, release the monitor in the failure block. The clrex instruction was designed for this: use it. Also see ARMARM v8-A B2.10.2: "Exclusive access instructions and Shareable memory locations". Differential Revision: http://reviews.llvm.org/D13033 llvm-svn: 248294
2015-09-23 01:22:58 +08:00
; RUN: llc < %s -mtriple=arm-linux-gnueabi -asm-verbose=false -verify-machineinstrs | FileCheck %s -check-prefix=CHECK-ARM
; RUN: llc < %s -mtriple=thumb-linux-gnueabi -asm-verbose=false -verify-machineinstrs | FileCheck %s -check-prefix=CHECK-THUMB
Replace the result usages while legalizing cmpxchg. We should update the usages to all of the results; otherwise, we might get assertion failure or SEGV during the type legalization of ATOMIC_CMP_SWAP_WITH_SUCCESS with two or more illegal types. For example, in the following sequence, both i8 and i1 might be illegal in some target, e.g. armv5, mipsel, mips64el, %0 = cmpxchg i8* %ptr, i8 %desire, i8 %new monotonic monotonic %1 = extractvalue { i8, i1 } %0, 1 Since both i8 and i1 should be legalized, the corresponding ATOMIC_CMP_SWAP_WITH_SUCCESS dag will be checked/replaced/updated twice. If we don't update the usage to *ALL* of the results in the first round, the DAG for extractvalue might be processed earlier. The GetPromotedInteger() will result in assertion failure, because its operand (i.e. the success bit of cmpxchg) is not promoted beforehand. llvm-svn: 213569
2014-07-22 01:33:44 +08:00
[ARM] Don't generate clrex for pre-v7 targets. Since r248294, we emit clrex, but it doesn't exist on v6. llvm-svn: 248640
2015-09-26 08:14:02 +08:00
; RUN: llc < %s -mtriple=armv6-linux-gnueabi -asm-verbose=false -verify-machineinstrs | FileCheck %s -check-prefix=CHECK-ARMV6
; RUN: llc < %s -mtriple=thumbv6-linux-gnueabi -asm-verbose=false -verify-machineinstrs | FileCheck %s -check-prefix=CHECK-THUMBV6
[ARM] Emit clrex in the expanded cmpxchg fail block. ARM counterpart to r248291: In the comparison failure block of a cmpxchg expansion, the initial ldrex/ldxr will not be followed by a matching strex/stxr. On ARM/AArch64, this unnecessarily ties up the execution monitor, which might have a negative performance impact on some uarchs. Instead, release the monitor in the failure block. The clrex instruction was designed for this: use it. Also see ARMARM v8-A B2.10.2: "Exclusive access instructions and Shareable memory locations". Differential Revision: http://reviews.llvm.org/D13033 llvm-svn: 248294
2015-09-23 01:22:58 +08:00
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -asm-verbose=false -verify-machineinstrs | FileCheck %s -check-prefix=CHECK-ARMV7
; RUN: llc < %s -mtriple=thumbv7-linux-gnueabi -asm-verbose=false -verify-machineinstrs | FileCheck %s -check-prefix=CHECK-THUMBV7
Replace the result usages while legalizing cmpxchg. We should update the usages to all of the results; otherwise, we might get assertion failure or SEGV during the type legalization of ATOMIC_CMP_SWAP_WITH_SUCCESS with two or more illegal types. For example, in the following sequence, both i8 and i1 might be illegal in some target, e.g. armv5, mipsel, mips64el, %0 = cmpxchg i8* %ptr, i8 %desire, i8 %new monotonic monotonic %1 = extractvalue { i8, i1 } %0, 1 Since both i8 and i1 should be legalized, the corresponding ATOMIC_CMP_SWAP_WITH_SUCCESS dag will be checked/replaced/updated twice. If we don't update the usage to *ALL* of the results in the first round, the DAG for extractvalue might be processed earlier. The GetPromotedInteger() will result in assertion failure, because its operand (i.e. the success bit of cmpxchg) is not promoted beforehand. llvm-svn: 213569
2014-07-22 01:33:44 +08:00
define zeroext i1 @test_cmpxchg_res_i8(i8* %addr, i8 %desired, i8 zeroext %new) {
[ARM] Make MachineVerifier more strict about terminators Fix the ARM backend's analyzeBranch so it doesn't ignore predicated return instructions, and make the MachineVerifier rule more strict. Differential Revision: https://reviews.llvm.org/D40061
2020-08-27 14:09:25 +08:00
; CHECK-ARM-LABEL: test_cmpxchg_res_i8:
; CHECK-ARM: .save {r4, lr}
; CHECK-ARM-NEXT: push {r4, lr}
; CHECK-ARM-NEXT: mov r4, r1
; CHECK-ARM-NEXT: bl __sync_val_compare_and_swap_1
; CHECK-ARM-NEXT: and r1, r4, #255
; CHECK-ARM-NEXT: sub r0, r0, r1
; CHECK-ARM-NEXT: rsbs r1, r0, #0
; CHECK-ARM-NEXT: adc r0, r0, r1
; CHECK-ARM-NEXT: pop {r4, lr}
; CHECK-ARM-NEXT: mov pc, lr
;
; CHECK-THUMB-LABEL: test_cmpxchg_res_i8:
; CHECK-THUMB: .save {r4, lr}
; CHECK-THUMB-NEXT: push {r4, lr}
; CHECK-THUMB-NEXT: movs r4, r1
; CHECK-THUMB-NEXT: bl __sync_val_compare_and_swap_1
; CHECK-THUMB-NEXT: movs r1, #255
; CHECK-THUMB-NEXT: ands r1, r4
; CHECK-THUMB-NEXT: subs r1, r0, r1
; CHECK-THUMB-NEXT: rsbs r0, r1, #0
; CHECK-THUMB-NEXT: adcs r0, r1
; CHECK-THUMB-NEXT: pop {r4}
; CHECK-THUMB-NEXT: pop {r1}
; CHECK-THUMB-NEXT: bx r1
;
; CHECK-ARMV6-LABEL: test_cmpxchg_res_i8:
; CHECK-ARMV6: uxtb r1, r1
; CHECK-ARMV6-NEXT: .LBB0_1:
; CHECK-ARMV6-NEXT: ldrexb r3, [r0]
; CHECK-ARMV6-NEXT: cmp r3, r1
; CHECK-ARMV6-NEXT: movne r0, #0
; CHECK-ARMV6-NEXT: bxne lr
; CHECK-ARMV6-NEXT: .LBB0_2:
; CHECK-ARMV6-NEXT: strexb r3, r2, [r0]
; CHECK-ARMV6-NEXT: cmp r3, #0
; CHECK-ARMV6-NEXT: moveq r0, #1
; CHECK-ARMV6-NEXT: bxeq lr
; CHECK-ARMV6-NEXT: b .LBB0_1
;
; CHECK-THUMBV6-LABEL: test_cmpxchg_res_i8:
; CHECK-THUMBV6: .save {r4, lr}
; CHECK-THUMBV6-NEXT: push {r4, lr}
; CHECK-THUMBV6-NEXT: mov r4, r1
; CHECK-THUMBV6-NEXT: bl __sync_val_compare_and_swap_1
; CHECK-THUMBV6-NEXT: uxtb r1, r4
; CHECK-THUMBV6-NEXT: subs r1, r0, r1
; CHECK-THUMBV6-NEXT: rsbs r0, r1, #0
; CHECK-THUMBV6-NEXT: adcs r0, r1
; CHECK-THUMBV6-NEXT: pop {r4, pc}
;
; CHECK-ARMV7-LABEL: test_cmpxchg_res_i8:
; CHECK-ARMV7: uxtb r1, r1
; CHECK-ARMV7-NEXT: .LBB0_1:
; CHECK-ARMV7-NEXT: ldrexb r3, [r0]
; CHECK-ARMV7-NEXT: cmp r3, r1
; CHECK-ARMV7-NEXT: bne .LBB0_3
; CHECK-ARMV7-NEXT: strexb r3, r2, [r0]
; CHECK-ARMV7-NEXT: cmp r3, #0
; CHECK-ARMV7-NEXT: moveq r0, #1
; CHECK-ARMV7-NEXT: bxeq lr
; CHECK-ARMV7-NEXT: b .LBB0_1
; CHECK-ARMV7-NEXT: .LBB0_3:
; CHECK-ARMV7-NEXT: mov r0, #0
; CHECK-ARMV7-NEXT: clrex
; CHECK-ARMV7-NEXT: bx lr
;
; CHECK-THUMBV7-LABEL: test_cmpxchg_res_i8:
; CHECK-THUMBV7: uxtb r1, r1
; CHECK-THUMBV7-NEXT: .LBB0_1:
; CHECK-THUMBV7-NEXT: ldrexb r3, [r0]
; CHECK-THUMBV7-NEXT: cmp r3, r1
; CHECK-THUMBV7-NEXT: bne .LBB0_3
; CHECK-THUMBV7-NEXT: strexb r3, r2, [r0]
; CHECK-THUMBV7-NEXT: cmp r3, #0
; CHECK-THUMBV7-NEXT: itt eq
; CHECK-THUMBV7-NEXT: moveq r0, #1
; CHECK-THUMBV7-NEXT: bxeq lr
; CHECK-THUMBV7-NEXT: b .LBB0_1
; CHECK-THUMBV7-NEXT: .LBB0_3:
; CHECK-THUMBV7-NEXT: movs r0, #0
; CHECK-THUMBV7-NEXT: clrex
; CHECK-THUMBV7-NEXT: bx lr
Replace the result usages while legalizing cmpxchg. We should update the usages to all of the results; otherwise, we might get assertion failure or SEGV during the type legalization of ATOMIC_CMP_SWAP_WITH_SUCCESS with two or more illegal types. For example, in the following sequence, both i8 and i1 might be illegal in some target, e.g. armv5, mipsel, mips64el, %0 = cmpxchg i8* %ptr, i8 %desire, i8 %new monotonic monotonic %1 = extractvalue { i8, i1 } %0, 1 Since both i8 and i1 should be legalized, the corresponding ATOMIC_CMP_SWAP_WITH_SUCCESS dag will be checked/replaced/updated twice. If we don't update the usage to *ALL* of the results in the first round, the DAG for extractvalue might be processed earlier. The GetPromotedInteger() will result in assertion failure, because its operand (i.e. the success bit of cmpxchg) is not promoted beforehand. llvm-svn: 213569
2014-07-22 01:33:44 +08:00
entry:
%0 = cmpxchg i8* %addr, i8 %desired, i8 %new monotonic monotonic
%1 = extractvalue { i8, i1 } %0, 1
ret i1 %1
}