summaryrefslogtreecommitdiffstats
path: root/llvm/test/CodeGen/X86/atomic-load-store-wide.ll
Commit message (Collapse)AuthorAgeFilesLines
* [X86] Prefer locked stack op over mfence for seq_cst 64-bit stores on 32-bit ↵Philip Reames2019-05-141-1/+1
| | | | | | | | | | targets This is a follow on to D58632, with the same logic. Given a memory operation which needs ordering, but doesn't need to modify any particular address, prefer to use a locked stack op over an mfence. Differential Revision: https://reviews.llvm.org/D61863 llvm-svn: 360649
* [X86] Use MOVQ for i64 atomic_stores when SSE2 is enabledCraig Topper2019-04-271-24/+32
| | | | | | | | | | | | | | | | Summary: If we have SSE2 we can use a MOVQ to store 64-bits and avoid falling back to a cmpxchg8b loop. If its a seq_cst store we need to insert an mfence after the store. Reviewers: spatel, RKSimon, reames, jfb, efriedma Reviewed By: RKSimon Subscribers: hiraditya, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60546 llvm-svn: 359368
* Recommit r358211 "[X86] Use FILD/FIST to implement i64 atomic load on 32-bit ↵Craig Topper2019-04-111-30/+28
| | | | | | | | | | | | targets with X87, but no SSE2" With correct test checks this time. If we have X87, but not SSE2 we can atomicaly load an i64 value into the significand of an 80-bit extended precision x87 register using fild. We can then use a fist instruction to convert it back to an i64 integ This matches what gcc and icc do for this case and removes an existing FIXME. llvm-svn: 358214
* Revert r358211 "[X86] Use FILD/FIST to implement i64 atomic load on 32-bit ↵Craig Topper2019-04-111-28/+30
| | | | | | | | targets with X87, but no SSE2" I seem to have messed up the test checks. llvm-svn: 358212
* [X86] Use FILD/FIST to implement i64 atomic load on 32-bit targets with X87, ↵Craig Topper2019-04-111-30/+28
| | | | | | | | | | | | but no SSE2 If we have X87, but not SSE2 we can atomicaly load an i64 value into the significand of an 80-bit extended precision x87 register using fild. We can then use a fist instruction to convert it back to an i64 integer and store it to a stack temporary. From there we can do two 32-bit loads to get the value into integer registers without worrying about atomicness. This matches what gcc and icc do for this case and removes an existing FIXME. Differential Revision: https://reviews.llvm.org/D60156 llvm-svn: 358211
* [X86] Pre-commit i64 volatile test case for D60156. NFCCraig Topper2019-04-111-0/+32
| | | | llvm-svn: 358210
* [X86] Use movq for i64 atomic load on 32-bit targets when sse2 is enableCraig Topper2019-03-221-2/+36
| | | | | | | | | | | | | | We used a lock cmpxchg8b to do i64 atomic loads. But if we have SSE2 we can do better and use a plain movq to do the load instead. I tried to just use an f64 atomic load and add isel patterns to MOVSD(which the domain fixing pass can turn to MOVQ), but the atomic_load SDNode in TargetSelectionDAG.td requires the type to be integer. So I've emitted VZEXT_LOAD instead which should be selected by isel to a MOVQ. Hopefully we don't need a specific atomic flavor of this. I kept the memory operand from the original AtomicSDNode. I wasn't sure if I might need to set the MOVolatile flag? I've left some FIXMEs for improvements we can do without SSE2. Differential Revision: https://reviews.llvm.org/D59679 llvm-svn: 356807
* [X86] Autogenerate complete checks. NFCCraig Topper2019-03-211-5/+44
| | | | llvm-svn: 356723
* X86: Do not use llc -march in tests.Matthias Braun2017-08-021-1/+1
| | | | | | | | | | | | | | | `llc -march` is problematic because it only switches the target architecture, but leaves the operating system unchanged. This occasionally leads to indeterministic tests because the OS from LLVM_DEFAULT_TARGET_TRIPLE is used. However we can simply always use `llc -mtriple` instead. This changes all the tests to do this to avoid people using -march when they copy and paste parts of tests. See also the discussion in https://reviews.llvm.org/D35287 llvm-svn: 309774
* Print "lock \t foo" instead of "lock \n foo".Rafael Espindola2015-05-261-4/+2
| | | | | | | | | | | This gets gas and llc -filetype=obj to agree on the order of prefixes. For llvm-mc we need to fix the asm parser to know that it makes a difference on which line the "lock" is in. Part of pr23594. llvm-svn: 238232
* [opaque pointer type] Add textual IR support for explicit type parameter to ↵David Blaikie2015-02-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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
* [X86] Make wide loads be managed by AtomicExpandRobin Morisset2014-09-231-4/+6
| | | | | | | | | | | | | | | | | | | | | | | Summary: AtomicExpand already had logic for expanding wide loads and stores on LL/SC architectures, and for expanding wide stores on CmpXchg architectures, but not for wide loads on CmpXchg architectures. This patch fills this hole, and makes use of this new feature in the X86 backend. Only one functionnal change: we now lose the SynchScope attribute. It is regrettable, but I have another patch that I will submit soon that will solve this for all of AtomicExpand (it seemed better to split it apart as it is a different concern). Test Plan: make check-all (lots of tests for this functionality already exist) Reviewers: jfb Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D5404 llvm-svn: 218332
* X86: expand atomics in IR instead of as MachineInstrs.Tim Northover2014-07-011-1/+1
| | | | | | | | | | | | The logic for expanding atomics that aren't natively supported in terms of cmpxchg loops is much simpler to express at the IR level. It also allows the normal optimisations and CodeGen improvements to help out with atomics, instead of using a limited set of possible instructions.. rdar://problem/13496295 llvm-svn: 212119
* Fix PR15355Michael Liao2013-03-061-1/+1
| | | | | | | | | | | | | - Clear 'mayStore' flag when loading from the atomic variable before the spin loop - Clear kill flag from one use to multiple use in registers forming the address to that atomic variable - don't use a physical register as live-in register in BB (neither entry nor landing pad.) by copying it into virtual register (patch by Cameron Zwarich) llvm-svn: 176538
* Error out on CodeGen of unaligned load/store. Fix test so it isn't ↵Eli Friedman2011-09-131-2/+2
| | | | | | accidentally testing that case. llvm-svn: 139641
* Hook up 64-bit atomic load/store on x86-32. I plan to write more efficient ↵Eli Friedman2011-08-241-0/+19
implementations eventually. llvm-svn: 138505
OpenPOWER on IntegriCloud