summaryrefslogtreecommitdiffstats
path: root/llvm/test/CodeGen/ARM/atomic-load-store.ll
Commit message (Collapse)AuthorAgeFilesLines
* [opaque pointer type] Add textual IR support for explicit type parameter to ↵David Blaikie2015-02-271-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Restore "[ARM, Fix] Fix emitLeading/TrailingFence on old ARM processors"Robin Morisset2014-09-181-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "[ARM, Fix] Fix emitLeading/TrailingFence on old ARM processors"Robin Morisset2014-09-171-23/+0
| | | | | | | | | | | It is breaking the build on the buildbots but works fine on my machine, I revert while trying to understand what happens (it appears to depend on the compiler used to build, I probably used a C++11 feature that is not perfectly supported by some of the buildbots). This reverts commit feb3176c4d006f99af8b40373abd56215a90e7cc. llvm-svn: 217973
* [ARM, Fix] Fix emitLeading/TrailingFence on old ARM processorsRobin Morisset2014-09-171-0/+23
| | | | | | | | | | | | | | | | | | | | | Summary: 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: aemerson, llvm-commits Differential Revision: http://reviews.llvm.org/D5304 llvm-svn: 217965
* SelectionDAG: skip barriers for unordered atomic operationsTim Northover2014-05-301-12/+25
| | | | | | | | | 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
* Fix broken CHECK lines.Benjamin Kramer2014-01-111-1/+1
| | | | llvm-svn: 199016
* [ARM] Constrain some register classes in EmitAtomicBinary64 so thatJoey Gouly2013-08-221-1/+1
| | | | | | we pass these tests with -verify-machineinstrs. llvm-svn: 189006
* ARM: relax the atomic release barrier to "dmb ishst" on SwiftTim Northover2013-07-031-6/+6
| | | | | | | | | | | 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
* Revert r185339 (ARM: relax the atomic release barrier to "dmb ishst")Tim Northover2013-07-011-40/+6
| | | | | | | | | Turns out I'd misread the architecture reference manual and thought that was a load/store-store barrier, when it's not. Thanks for pointing it out Eli! llvm-svn: 185356
* ARM: relax the atomic release barrier to "dmb ishst"Tim Northover2013-07-011-6/+40
| | | | | | | | | | | I believe the full "dmb ish" barrier is not required to guarantee release semantics for atomic operations. The weaker "dmb ishst" prevents previous operations being reordered with a store executed afterwards, which is enough. A key point to note (fortunately already correct) is that this barrier alone is *insufficient* for sequential consistency, no matter how liberally placed. llvm-svn: 185339
* Add missing case to switch statement - DAGTypeLegalizer::ExpandIntegerResultLang Hames2013-06-281-0/+15
| | | | | | | | | | | | 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
* Some additional tests for Thumb atomic load and store (which I somehow ↵Eli Friedman2011-09-191-0/+15
| | | | | | forgot to commit earlier). llvm-svn: 140074
* Some legalization fixes for atomic load and store.Eli Friedman2011-09-151-0/+9
| | | | llvm-svn: 139851
* Relax the MemOperands on atomics a bit. Fixes -verify-machineinstrs ↵Eli Friedman2011-09-071-1/+1
| | | | | | | | 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
* Don't fast-isel for atomic load/store; some cases require extra handling ↵Eli Friedman2011-09-021-0/+1
| | | | | | missing from fast-isel. llvm-svn: 139044
* Atomic load/store on ARM/Thumb.Eli Friedman2011-08-261-0/+31
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
OpenPOWER on IntegriCloud