Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2014-08-21T21:50:01+00:00 2014-08-21T21:50:01+00:00 Robin Morisset morisset@google.com 2014-08-21T21:50:01+00:00 urn:sha1:59c23cd946e6df7bef50e02fa28797469fecd805 AtomicExpandLoadLinked is currently rather ARM-specific. This patch is the first of a group that aim at making it more target-independent. See http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075873.html for details The command line option is "atomic-expand" llvm-svn: 216231 2014-07-07T09:06:35+00:00 Tim Northover tnorthover@apple.com 2014-07-07T09:06:35+00:00 urn:sha1:55beb64bd063196acda5dd51e7e63f2ceae48ee7 We've been performing the wrong operation on ARM for "atomicrmw nand" for years, since "a NAND b" is "~(a & b)" rather than ARM's very tempting "a & ~b". This bled over into the generic expansion pass. So I assume no-one has ever actually tried to do an atomic nand in the real world. Oh well. llvm-svn: 212443 2014-06-13T16:45:52+00:00 Tim Northover tnorthover@apple.com 2014-06-13T16:45:52+00:00 urn:sha1:20b9f739eb84af9657c824f0d08396031a9e21d8 This also simplifies the IR we create slightly: instead of working out where success & failure should go manually, it turns out we can just always jump to a success/failure block created for the purpose. Later phases will sort out the mess without much difficulty. llvm-svn: 210917 2014-06-13T16:45:36+00:00 Tim Northover tnorthover@apple.com 2014-06-13T16:45:36+00:00 urn:sha1:d039abdeeb2ac2476277c275ed4065440ef1fbb0 This has two benefits: it makes the result more suitable for direct insertaion into the struct to emulate the new cmpxchg, and it means the name we give the instruction matches its actual effect better. llvm-svn: 210916 2014-06-13T14:24:07+00:00 Tim Northover tnorthover@apple.com 2014-06-13T14:24:07+00:00 urn:sha1:420a216817def01816186910a2e35885c9201951 This commit adds a weak variant of the cmpxchg operation, as described in C++11. A cmpxchg instruction with this modifier is permitted to fail to store, even if the comparison indicated it should. As a result, cmpxchg instructions must return a flag indicating success in addition to their original iN value loaded. Thus, for uniformity *all* cmpxchg instructions now return "{ iN, i1 }". The second flag is 1 when the store succeeded. At the DAG level, a new ATOMIC_CMP_SWAP_WITH_SUCCESS node has been added as the natural representation for the new cmpxchg instructions. It is a strong cmpxchg. By default this gets Expanded to the existing ATOMIC_CMP_SWAP during Legalization, so existing backends should see no change in behaviour. If they wish to deal with the enhanced node instead, they can call setOperationAction on it. Beware: as a node with 2 results, it cannot be selected from TableGen. Currently, no use is made of the extra information provided in this patch. Test updates are almost entirely adapting the input IR to the new scheme. Summary for out of tree users: ------------------------------ + Legacy Bitcode files are upgraded during read. + Legacy assembly IR files will be invalid. + Front-ends must adapt to different type for "cmpxchg". + Backends should be unaffected by default. llvm-svn: 210903 2014-06-09T22:42:55+00:00 Alp Toker alp@nuanti.com 2014-06-09T22:42:55+00:00 urn:sha1:d3d017cf00714c7d376a3cf87d2a17002e12cac7 We can just split targets_to_build in one place and make it immutable. llvm-svn: 210496 2014-04-17T18:22:47+00:00 Tim Northover tnorthover@apple.com 2014-04-17T18:22:47+00:00 urn:sha1:037f26f2123e10f8b5c01cf5eb2cceaa254ad9b7 Still only 32-bit ARM using it at this stage, but the promotion allows direct testing via opt and is a reasonably self-contained patch on the way to switching ARM64. At this point, other targets should be able to make use of it without too much difficulty if they want. (See ARM64 commit coming soon for an example). llvm-svn: 206485