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-load-store.ll

108 lines
2.8 KiB
LLVM
Raw Normal View History

Relax the MemOperands on atomics a bit. Fixes -verify-machineinstrs failures for atomic laod/store on ARM. (The fix for the related failures on x86 is going to be nastier because we actually need Acquire memoperands attached to the atomic load instrs, etc.) llvm-svn: 139221
2011-09-07 10:23:42 +08:00
; RUN: llc < %s -mtriple=armv7-apple-ios -verify-machineinstrs | FileCheck %s -check-prefix=ARM
Don't fast-isel for atomic load/store; some cases require extra handling missing from fast-isel. llvm-svn: 139044
2011-09-03 06:33:24 +08:00
; RUN: llc < %s -mtriple=armv7-apple-ios -O0 | FileCheck %s -check-prefix=ARM
[ARM] Constrain some register classes in EmitAtomicBinary64 so that we pass these tests with -verify-machineinstrs. llvm-svn: 189006
2013-08-22 20:19:24 +08:00
; RUN: llc < %s -mtriple=thumbv7-apple-ios -verify-machineinstrs | FileCheck %s -check-prefix=THUMBTWO
Atomic load/store on ARM/Thumb. I don't really like the patterns, but I'm having trouble coming up with a better way to handle them. I plan on making other targets use the same legalization ARM-without-memory-barriers is using... it's not especially efficient, but if anyone cares, it's not that hard to fix for a given target if there's some better lowering. llvm-svn: 138621
2011-08-26 10:59:24 +08:00
; RUN: llc < %s -mtriple=thumbv6-apple-ios | FileCheck %s -check-prefix=THUMBONE
Fix broken CHECK lines. llvm-svn: 199016
2014-01-12 05:06:00 +08:00
; RUN: llc < %s -mtriple=armv4-apple-ios | FileCheck %s -check-prefix=ARMV4
Restore "[ARM, Fix] Fix emitLeading/TrailingFence on old ARM processors" Summary: This patch was originally in D5304 (I could not find a way to reopen that revision). It was accepted, commited and broke the build bots because the overloading of the constructor of ArrayRef for braced initializer lists is not supported by all toolchains. I then reverted it, and propose this fixed version that uses a plain C array instead in makeDMB (that array is then converted implicitly to an ArrayRef, but that is not behind an ifdef). Could someone confirm me whether initialization lists for plain C arrays are supported by every toolchain used to build llvm ? Otherwise I can just initialize the array in the old way: args[0] = ...; .. ; args[5] = ...; Below is the description of the original patch: ``` I had only tested this code for ARMv7 and ARMv8. This patch adds several fallback paths if the processor does not support dmb ish: - dmb sy if a cortex-M with support for dmb - mcr p15, #0, r0, c7, c10, #5 for ARMv6 (special instruction equivalent to a DMB) These fallback paths were chosen based on the code for fence seq_cst. Thanks to luqmana for having noticed this bug. ``` Test Plan: Added more cases to atomic-load-store.ll + make check-all Reviewers: jfb, t.p.northover, luqmana Subscribers: llvm-commits, aemerson Differential Revision: http://reviews.llvm.org/D5386 llvm-svn: 218066
2014-09-19 02:56:04 +08:00
; RUN: llc < %s -mtriple=armv6-apple-ios | FileCheck %s -check-prefix=ARMV6
; RUN: llc < %s -mtriple=thumbv7m-apple-ios | FileCheck %s -check-prefix=THUMBM
Atomic load/store on ARM/Thumb. I don't really like the patterns, but I'm having trouble coming up with a better way to handle them. I plan on making other targets use the same legalization ARM-without-memory-barriers is using... it's not especially efficient, but if anyone cares, it's not that hard to fix for a given target if there's some better lowering. llvm-svn: 138621
2011-08-26 10:59:24 +08:00
define void @test1(i32* %ptr, i32 %val1) {
SelectionDAG: skip barriers for unordered atomic operations Unordered is strictly weaker than monotonic, so if the latter doesn't have any barriers then the former certainly shouldn't. rdar://problem/16548260 llvm-svn: 209901
2014-05-30 22:41:51 +08:00
; ARM-LABEL: test1
ARM: relax the atomic release barrier to "dmb ishst" on Swift Swift cores implement store barriers that are stronger than the ARM specification but weaker than general barriers. They are, in fact, just about enough to provide the ordering needed for atomic operations with release semantics. This patch makes use of that quirk. llvm-svn: 185527
2013-07-03 17:20:36 +08:00
; ARM: dmb {{ish$}}
Atomic load/store on ARM/Thumb. I don't really like the patterns, but I'm having trouble coming up with a better way to handle them. I plan on making other targets use the same legalization ARM-without-memory-barriers is using... it's not especially efficient, but if anyone cares, it's not that hard to fix for a given target if there's some better lowering. llvm-svn: 138621
2011-08-26 10:59:24 +08:00
; ARM-NEXT: str
ARM: relax the atomic release barrier to "dmb ishst" on Swift Swift cores implement store barriers that are stronger than the ARM specification but weaker than general barriers. They are, in fact, just about enough to provide the ordering needed for atomic operations with release semantics. This patch makes use of that quirk. llvm-svn: 185527
2013-07-03 17:20:36 +08:00
; ARM-NEXT: dmb {{ish$}}
SelectionDAG: skip barriers for unordered atomic operations Unordered is strictly weaker than monotonic, so if the latter doesn't have any barriers then the former certainly shouldn't. rdar://problem/16548260 llvm-svn: 209901
2014-05-30 22:41:51 +08:00
; THUMBONE-LABEL: test1
Atomic load/store on ARM/Thumb. I don't really like the patterns, but I'm having trouble coming up with a better way to handle them. I plan on making other targets use the same legalization ARM-without-memory-barriers is using... it's not especially efficient, but if anyone cares, it's not that hard to fix for a given target if there's some better lowering. llvm-svn: 138621
2011-08-26 10:59:24 +08:00
; THUMBONE: __sync_lock_test_and_set_4
SelectionDAG: skip barriers for unordered atomic operations Unordered is strictly weaker than monotonic, so if the latter doesn't have any barriers then the former certainly shouldn't. rdar://problem/16548260 llvm-svn: 209901
2014-05-30 22:41:51 +08:00
; THUMBTWO-LABEL: test1
ARM: relax the atomic release barrier to "dmb ishst" on Swift Swift cores implement store barriers that are stronger than the ARM specification but weaker than general barriers. They are, in fact, just about enough to provide the ordering needed for atomic operations with release semantics. This patch makes use of that quirk. llvm-svn: 185527
2013-07-03 17:20:36 +08:00
; THUMBTWO: dmb {{ish$}}
Atomic load/store on ARM/Thumb. I don't really like the patterns, but I'm having trouble coming up with a better way to handle them. I plan on making other targets use the same legalization ARM-without-memory-barriers is using... it's not especially efficient, but if anyone cares, it's not that hard to fix for a given target if there's some better lowering. llvm-svn: 138621
2011-08-26 10:59:24 +08:00
; THUMBTWO-NEXT: str
ARM: relax the atomic release barrier to "dmb ishst" on Swift Swift cores implement store barriers that are stronger than the ARM specification but weaker than general barriers. They are, in fact, just about enough to provide the ordering needed for atomic operations with release semantics. This patch makes use of that quirk. llvm-svn: 185527
2013-07-03 17:20:36 +08:00
; THUMBTWO-NEXT: dmb {{ish$}}
Restore "[ARM, Fix] Fix emitLeading/TrailingFence on old ARM processors" Summary: This patch was originally in D5304 (I could not find a way to reopen that revision). It was accepted, commited and broke the build bots because the overloading of the constructor of ArrayRef for braced initializer lists is not supported by all toolchains. I then reverted it, and propose this fixed version that uses a plain C array instead in makeDMB (that array is then converted implicitly to an ArrayRef, but that is not behind an ifdef). Could someone confirm me whether initialization lists for plain C arrays are supported by every toolchain used to build llvm ? Otherwise I can just initialize the array in the old way: args[0] = ...; .. ; args[5] = ...; Below is the description of the original patch: ``` I had only tested this code for ARMv7 and ARMv8. This patch adds several fallback paths if the processor does not support dmb ish: - dmb sy if a cortex-M with support for dmb - mcr p15, #0, r0, c7, c10, #5 for ARMv6 (special instruction equivalent to a DMB) These fallback paths were chosen based on the code for fence seq_cst. Thanks to luqmana for having noticed this bug. ``` Test Plan: Added more cases to atomic-load-store.ll + make check-all Reviewers: jfb, t.p.northover, luqmana Subscribers: llvm-commits, aemerson Differential Revision: http://reviews.llvm.org/D5386 llvm-svn: 218066
2014-09-19 02:56:04 +08:00
; ARMV6-LABEL: test1
; ARMV6: mcr p15, #0, {{r[0-9]*}}, c7, c10, #5
; ARMV6: str
; ARMV6: mcr p15, #0, {{r[0-9]*}}, c7, c10, #5
; THUMBM-LABEL: test1
; THUMBM: dmb sy
; THUMBM: str
; THUMBM: dmb sy
Atomic load/store on ARM/Thumb. I don't really like the patterns, but I'm having trouble coming up with a better way to handle them. I plan on making other targets use the same legalization ARM-without-memory-barriers is using... it's not especially efficient, but if anyone cares, it's not that hard to fix for a given target if there's some better lowering. llvm-svn: 138621
2011-08-26 10:59:24 +08:00
store atomic i32 %val1, i32* %ptr seq_cst, align 4
ret void
}
define i32 @test2(i32* %ptr) {
SelectionDAG: skip barriers for unordered atomic operations Unordered is strictly weaker than monotonic, so if the latter doesn't have any barriers then the former certainly shouldn't. rdar://problem/16548260 llvm-svn: 209901
2014-05-30 22:41:51 +08:00
; ARM-LABEL: test2
Atomic load/store on ARM/Thumb. I don't really like the patterns, but I'm having trouble coming up with a better way to handle them. I plan on making other targets use the same legalization ARM-without-memory-barriers is using... it's not especially efficient, but if anyone cares, it's not that hard to fix for a given target if there's some better lowering. llvm-svn: 138621
2011-08-26 10:59:24 +08:00
; ARM: ldr
ARM: relax the atomic release barrier to "dmb ishst" on Swift Swift cores implement store barriers that are stronger than the ARM specification but weaker than general barriers. They are, in fact, just about enough to provide the ordering needed for atomic operations with release semantics. This patch makes use of that quirk. llvm-svn: 185527
2013-07-03 17:20:36 +08:00
; ARM-NEXT: dmb {{ish$}}
SelectionDAG: skip barriers for unordered atomic operations Unordered is strictly weaker than monotonic, so if the latter doesn't have any barriers then the former certainly shouldn't. rdar://problem/16548260 llvm-svn: 209901
2014-05-30 22:41:51 +08:00
; THUMBONE-LABEL: test2
Atomic load/store on ARM/Thumb. I don't really like the patterns, but I'm having trouble coming up with a better way to handle them. I plan on making other targets use the same legalization ARM-without-memory-barriers is using... it's not especially efficient, but if anyone cares, it's not that hard to fix for a given target if there's some better lowering. llvm-svn: 138621
2011-08-26 10:59:24 +08:00
; THUMBONE: __sync_val_compare_and_swap_4
SelectionDAG: skip barriers for unordered atomic operations Unordered is strictly weaker than monotonic, so if the latter doesn't have any barriers then the former certainly shouldn't. rdar://problem/16548260 llvm-svn: 209901
2014-05-30 22:41:51 +08:00
; THUMBTWO-LABEL: test2
Atomic load/store on ARM/Thumb. I don't really like the patterns, but I'm having trouble coming up with a better way to handle them. I plan on making other targets use the same legalization ARM-without-memory-barriers is using... it's not especially efficient, but if anyone cares, it's not that hard to fix for a given target if there's some better lowering. llvm-svn: 138621
2011-08-26 10:59:24 +08:00
; THUMBTWO: ldr
ARM: relax the atomic release barrier to "dmb ishst" on Swift Swift cores implement store barriers that are stronger than the ARM specification but weaker than general barriers. They are, in fact, just about enough to provide the ordering needed for atomic operations with release semantics. This patch makes use of that quirk. llvm-svn: 185527
2013-07-03 17:20:36 +08:00
; THUMBTWO-NEXT: dmb {{ish$}}
Restore "[ARM, Fix] Fix emitLeading/TrailingFence on old ARM processors" Summary: This patch was originally in D5304 (I could not find a way to reopen that revision). It was accepted, commited and broke the build bots because the overloading of the constructor of ArrayRef for braced initializer lists is not supported by all toolchains. I then reverted it, and propose this fixed version that uses a plain C array instead in makeDMB (that array is then converted implicitly to an ArrayRef, but that is not behind an ifdef). Could someone confirm me whether initialization lists for plain C arrays are supported by every toolchain used to build llvm ? Otherwise I can just initialize the array in the old way: args[0] = ...; .. ; args[5] = ...; Below is the description of the original patch: ``` I had only tested this code for ARMv7 and ARMv8. This patch adds several fallback paths if the processor does not support dmb ish: - dmb sy if a cortex-M with support for dmb - mcr p15, #0, r0, c7, c10, #5 for ARMv6 (special instruction equivalent to a DMB) These fallback paths were chosen based on the code for fence seq_cst. Thanks to luqmana for having noticed this bug. ``` Test Plan: Added more cases to atomic-load-store.ll + make check-all Reviewers: jfb, t.p.northover, luqmana Subscribers: llvm-commits, aemerson Differential Revision: http://reviews.llvm.org/D5386 llvm-svn: 218066
2014-09-19 02:56:04 +08:00
; ARMV6-LABEL: test2
; ARMV6: ldr
; ARMV6: mcr p15, #0, {{r[0-9]*}}, c7, c10, #5
; THUMBM-LABEL: test2
; THUMBM: ldr
; THUMBM: dmb sy
[opaque pointer type] Add textual IR support for explicit type parameter to load instruction Essentially the same as the GEP change in r230786. A similar migration script can be used to update test cases, though a few more test case improvements/changes were required this time around: (r229269-r229278) import fileinput import sys import re pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)") for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line)) Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7649 llvm-svn: 230794
2015-02-28 05:17:42 +08:00
%val = load atomic i32, i32* %ptr seq_cst, align 4
Atomic load/store on ARM/Thumb. I don't really like the patterns, but I'm having trouble coming up with a better way to handle them. I plan on making other targets use the same legalization ARM-without-memory-barriers is using... it's not especially efficient, but if anyone cares, it's not that hard to fix for a given target if there's some better lowering. llvm-svn: 138621
2011-08-26 10:59:24 +08:00
ret i32 %val
}
Some legalization fixes for atomic load and store. llvm-svn: 139851
2011-09-16 05:20:49 +08:00
define void @test3(i8* %ptr1, i8* %ptr2) {
SelectionDAG: skip barriers for unordered atomic operations Unordered is strictly weaker than monotonic, so if the latter doesn't have any barriers then the former certainly shouldn't. rdar://problem/16548260 llvm-svn: 209901
2014-05-30 22:41:51 +08:00
; ARM-LABEL: test3
; ARM-NOT: dmb
Some legalization fixes for atomic load and store. llvm-svn: 139851
2011-09-16 05:20:49 +08:00
; ARM: ldrb
SelectionDAG: skip barriers for unordered atomic operations Unordered is strictly weaker than monotonic, so if the latter doesn't have any barriers then the former certainly shouldn't. rdar://problem/16548260 llvm-svn: 209901
2014-05-30 22:41:51 +08:00
; ARM-NOT: dmb
Some legalization fixes for atomic load and store. llvm-svn: 139851
2011-09-16 05:20:49 +08:00
; ARM: strb
SelectionDAG: skip barriers for unordered atomic operations Unordered is strictly weaker than monotonic, so if the latter doesn't have any barriers then the former certainly shouldn't. rdar://problem/16548260 llvm-svn: 209901
2014-05-30 22:41:51 +08:00
; ARM-NOT: dmb
; ARM: bx lr
; THUMBTWO-LABEL: test3
; THUMBTWO-NOT: dmb
Some additional tests for Thumb atomic load and store (which I somehow forgot to commit earlier). llvm-svn: 140074
2011-09-20 06:02:33 +08:00
; THUMBTWO: ldrb
SelectionDAG: skip barriers for unordered atomic operations Unordered is strictly weaker than monotonic, so if the latter doesn't have any barriers then the former certainly shouldn't. rdar://problem/16548260 llvm-svn: 209901
2014-05-30 22:41:51 +08:00
; THUMBTWO-NOT: dmb
Some additional tests for Thumb atomic load and store (which I somehow forgot to commit earlier). llvm-svn: 140074
2011-09-20 06:02:33 +08:00
; THUMBTWO: strb
SelectionDAG: skip barriers for unordered atomic operations Unordered is strictly weaker than monotonic, so if the latter doesn't have any barriers then the former certainly shouldn't. rdar://problem/16548260 llvm-svn: 209901
2014-05-30 22:41:51 +08:00
; THUMBTWO-NOT: dmb
; THUMBTWO: bx lr
; THUMBONE-LABEL: test3
; THUMBONE-NOT: dmb
Some additional tests for Thumb atomic load and store (which I somehow forgot to commit earlier). llvm-svn: 140074
2011-09-20 06:02:33 +08:00
; THUMBONE: ldrb
SelectionDAG: skip barriers for unordered atomic operations Unordered is strictly weaker than monotonic, so if the latter doesn't have any barriers then the former certainly shouldn't. rdar://problem/16548260 llvm-svn: 209901
2014-05-30 22:41:51 +08:00
; THUMBONE-NOT: dmb
Some additional tests for Thumb atomic load and store (which I somehow forgot to commit earlier). llvm-svn: 140074
2011-09-20 06:02:33 +08:00
; THUMBONE: strb
SelectionDAG: skip barriers for unordered atomic operations Unordered is strictly weaker than monotonic, so if the latter doesn't have any barriers then the former certainly shouldn't. rdar://problem/16548260 llvm-svn: 209901
2014-05-30 22:41:51 +08:00
; THUMBONE-NOT: dmb
Restore "[ARM, Fix] Fix emitLeading/TrailingFence on old ARM processors" Summary: This patch was originally in D5304 (I could not find a way to reopen that revision). It was accepted, commited and broke the build bots because the overloading of the constructor of ArrayRef for braced initializer lists is not supported by all toolchains. I then reverted it, and propose this fixed version that uses a plain C array instead in makeDMB (that array is then converted implicitly to an ArrayRef, but that is not behind an ifdef). Could someone confirm me whether initialization lists for plain C arrays are supported by every toolchain used to build llvm ? Otherwise I can just initialize the array in the old way: args[0] = ...; .. ; args[5] = ...; Below is the description of the original patch: ``` I had only tested this code for ARMv7 and ARMv8. This patch adds several fallback paths if the processor does not support dmb ish: - dmb sy if a cortex-M with support for dmb - mcr p15, #0, r0, c7, c10, #5 for ARMv6 (special instruction equivalent to a DMB) These fallback paths were chosen based on the code for fence seq_cst. Thanks to luqmana for having noticed this bug. ``` Test Plan: Added more cases to atomic-load-store.ll + make check-all Reviewers: jfb, t.p.northover, luqmana Subscribers: llvm-commits, aemerson Differential Revision: http://reviews.llvm.org/D5386 llvm-svn: 218066
2014-09-19 02:56:04 +08:00
; ARMV6-LABEL: test3
; ARMV6-NOT: mcr
; THUMBM-LABEL: test3
; THUMBM-NOT: dmb sy
[opaque pointer type] Add textual IR support for explicit type parameter to load instruction Essentially the same as the GEP change in r230786. A similar migration script can be used to update test cases, though a few more test case improvements/changes were required this time around: (r229269-r229278) import fileinput import sys import re pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)") for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line)) Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7649 llvm-svn: 230794
2015-02-28 05:17:42 +08:00
%val = load atomic i8, i8* %ptr1 unordered, align 1
Some legalization fixes for atomic load and store. llvm-svn: 139851
2011-09-16 05:20:49 +08:00
store atomic i8 %val, i8* %ptr2 unordered, align 1
ret void
}
Some additional tests for Thumb atomic load and store (which I somehow forgot to commit earlier). llvm-svn: 140074
2011-09-20 06:02:33 +08:00
define void @test4(i8* %ptr1, i8* %ptr2) {
SelectionDAG: skip barriers for unordered atomic operations Unordered is strictly weaker than monotonic, so if the latter doesn't have any barriers then the former certainly shouldn't. rdar://problem/16548260 llvm-svn: 209901
2014-05-30 22:41:51 +08:00
; THUMBONE-LABEL: test4
Some additional tests for Thumb atomic load and store (which I somehow forgot to commit earlier). llvm-svn: 140074
2011-09-20 06:02:33 +08:00
; THUMBONE: ___sync_val_compare_and_swap_1
; THUMBONE: ___sync_lock_test_and_set_1
Restore "[ARM, Fix] Fix emitLeading/TrailingFence on old ARM processors" Summary: This patch was originally in D5304 (I could not find a way to reopen that revision). It was accepted, commited and broke the build bots because the overloading of the constructor of ArrayRef for braced initializer lists is not supported by all toolchains. I then reverted it, and propose this fixed version that uses a plain C array instead in makeDMB (that array is then converted implicitly to an ArrayRef, but that is not behind an ifdef). Could someone confirm me whether initialization lists for plain C arrays are supported by every toolchain used to build llvm ? Otherwise I can just initialize the array in the old way: args[0] = ...; .. ; args[5] = ...; Below is the description of the original patch: ``` I had only tested this code for ARMv7 and ARMv8. This patch adds several fallback paths if the processor does not support dmb ish: - dmb sy if a cortex-M with support for dmb - mcr p15, #0, r0, c7, c10, #5 for ARMv6 (special instruction equivalent to a DMB) These fallback paths were chosen based on the code for fence seq_cst. Thanks to luqmana for having noticed this bug. ``` Test Plan: Added more cases to atomic-load-store.ll + make check-all Reviewers: jfb, t.p.northover, luqmana Subscribers: llvm-commits, aemerson Differential Revision: http://reviews.llvm.org/D5386 llvm-svn: 218066
2014-09-19 02:56:04 +08:00
; ARMV6-LABEL: test4
; THUMBM-LABEL: test4
[opaque pointer type] Add textual IR support for explicit type parameter to load instruction Essentially the same as the GEP change in r230786. A similar migration script can be used to update test cases, though a few more test case improvements/changes were required this time around: (r229269-r229278) import fileinput import sys import re pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)") for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line)) Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7649 llvm-svn: 230794
2015-02-28 05:17:42 +08:00
%val = load atomic i8, i8* %ptr1 seq_cst, align 1
Some additional tests for Thumb atomic load and store (which I somehow forgot to commit earlier). llvm-svn: 140074
2011-09-20 06:02:33 +08:00
store atomic i8 %val, i8* %ptr2 seq_cst, align 1
ret void
}
Add missing case to switch statement - DAGTypeLegalizer::ExpandIntegerResult should expand ATOMIC_CMP_SWAP nodes the same way that it does for ATOMIC_SWAP. Since ATOMIC_LOADs on some targets (e.g. older ARM variants) get legalized to ATOMIC_CMP_SWAPs, the missing case had been causing i64 atomic loads to crash during isel. <rdar://problem/14074644> llvm-svn: 185186
2013-06-29 02:36:42 +08:00
define i64 @test_old_load_64bit(i64* %p) {
SelectionDAG: skip barriers for unordered atomic operations Unordered is strictly weaker than monotonic, so if the latter doesn't have any barriers then the former certainly shouldn't. rdar://problem/16548260 llvm-svn: 209901
2014-05-30 22:41:51 +08:00
; ARMV4-LABEL: test_old_load_64bit
Add missing case to switch statement - DAGTypeLegalizer::ExpandIntegerResult should expand ATOMIC_CMP_SWAP nodes the same way that it does for ATOMIC_SWAP. Since ATOMIC_LOADs on some targets (e.g. older ARM variants) get legalized to ATOMIC_CMP_SWAPs, the missing case had been causing i64 atomic loads to crash during isel. <rdar://problem/14074644> llvm-svn: 185186
2013-06-29 02:36:42 +08:00
; ARMV4: ___sync_val_compare_and_swap_8
[opaque pointer type] Add textual IR support for explicit type parameter to load instruction Essentially the same as the GEP change in r230786. A similar migration script can be used to update test cases, though a few more test case improvements/changes were required this time around: (r229269-r229278) import fileinput import sys import re pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)") for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line)) Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7649 llvm-svn: 230794
2015-02-28 05:17:42 +08:00
%1 = load atomic i64, i64* %p seq_cst, align 8
Add missing case to switch statement - DAGTypeLegalizer::ExpandIntegerResult should expand ATOMIC_CMP_SWAP nodes the same way that it does for ATOMIC_SWAP. Since ATOMIC_LOADs on some targets (e.g. older ARM variants) get legalized to ATOMIC_CMP_SWAPs, the missing case had been causing i64 atomic loads to crash during isel. <rdar://problem/14074644> llvm-svn: 185186
2013-06-29 02:36:42 +08:00
ret i64 %1
}
define void @test_old_store_64bit(i64* %p, i64 %v) {
SelectionDAG: skip barriers for unordered atomic operations Unordered is strictly weaker than monotonic, so if the latter doesn't have any barriers then the former certainly shouldn't. rdar://problem/16548260 llvm-svn: 209901
2014-05-30 22:41:51 +08:00
; ARMV4-LABEL: test_old_store_64bit
Add missing case to switch statement - DAGTypeLegalizer::ExpandIntegerResult should expand ATOMIC_CMP_SWAP nodes the same way that it does for ATOMIC_SWAP. Since ATOMIC_LOADs on some targets (e.g. older ARM variants) get legalized to ATOMIC_CMP_SWAPs, the missing case had been causing i64 atomic loads to crash during isel. <rdar://problem/14074644> llvm-svn: 185186
2013-06-29 02:36:42 +08:00
; ARMV4: ___sync_lock_test_and_set_8
store atomic i64 %v, i64* %p seq_cst, align 8
ret void
}