6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2025-08-04 06:26:28 +00:00
Code Issues Projects Releases Wiki Activity

IR: add a second ordering operand to cmpxhg for failure

Browse Source 
The syntax for "cmpxchg" should now look something like:

	cmpxchg i32* %addr, i32 42, i32 3 acquire monotonic

where the second ordering argument gives the required semantics in the case
that no exchange takes place. It should be no stronger than the first ordering
constraint and cannot be either "release" or "acq_rel" (since no store will
have taken place).

rdar://problem/15996804

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203559 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Tim Northover
2014-03-11 10:48:52 +00:00
parent fb411c8b8c
commit ca396e391e
60 changed files with 489 additions and 288 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
docs/LangRef.rst
View File

@@ -1496,7 +1496,7 @@ Atomic Memory Ordering Constraints
Atomic instructions (:ref:`cmpxchg <i_cmpxchg>`,
:ref:`atomicrmw <i_atomicrmw>`, :ref:`fence <i_fence>`,
:ref:`atomic load <i_load>`, and :ref:`atomic store <i_store>`) take
an ordering parameter that determines which other atomic instructions on
ordering parameters that determine which other atomic instructions on
the same address they *synchronize with*. These semantics are borrowed
from Java and C++0x, but are somewhat more colloquial. If these
descriptions aren't precise enough, check those specs (see spec
@@ -4990,7 +4990,7 @@ Syntax:
::
cmpxchg [volatile] <ty>* <pointer>, <ty> <cmp>, <ty> <new> [singlethread] <ordering> ; yields {ty}
cmpxchg [volatile] <ty>* <pointer>, <ty> <cmp>, <ty> <new> [singlethread] <success ordering> <failure ordering> ; yields {ty}
Overview:
"""""""""
@@ -5013,8 +5013,11 @@ type, and the type of '<pointer>' must be a pointer to that type. If the
to modify the number or order of execution of this ``cmpxchg`` with
other :ref:`volatile operations <volatile>`.
The :ref:`ordering <ordering>` argument specifies how this ``cmpxchg``
synchronizes with other atomic operations.
The success and failure :ref:`ordering <ordering>` arguments specify how this
``cmpxchg`` synchronizes with other atomic operations. The both ordering
parameters must be at least ``monotonic``, the ordering constraint on failure
must be no stronger than that on success, and the failure ordering cannot be
either ``release`` or ``acq_rel``.
The optional "``singlethread``" argument declares that the ``cmpxchg``
is only atomic with respect to code (usually signal handlers) running in
@@ -5032,10 +5035,9 @@ operand is read and compared to '``<cmp>``'; if the read value is the
equal, '``<new>``' is written. The original value at the location is
returned.
A successful ``cmpxchg`` is a read-modify-write instruction for the purpose
of identifying release sequences. A failed ``cmpxchg`` is equivalent to an
atomic load with an ordering parameter determined by dropping any
``release`` part of the ``cmpxchg``'s ordering.
A successful ``cmpxchg`` is a read-modify-write instruction for the purpose of
identifying release sequences. A failed ``cmpxchg`` is equivalent to an atomic
load with an ordering parameter determined the second ordering parameter.
Example:
""""""""
@@ -5049,7 +5051,7 @@ Example:
loop:
%cmp = phi i32 [ %orig, %entry ], [%old, %loop]
%squared = mul i32 %cmp, %cmp
%old = cmpxchg i32* %ptr, i32 %cmp, i32 %squared ; yields {i32}
%old = cmpxchg i32* %ptr, i32 %cmp, i32 %squared acq_rel monotonic ; yields {i32}
%success = icmp eq i32 %cmp, %old
br i1 %success, label %done, label %loop