diff options
| author | Eli Friedman <eli.friedman@gmail.com> | 2011-08-09 23:02:53 +0000 |
|---|---|---|
| committer | Eli Friedman <eli.friedman@gmail.com> | 2011-08-09 23:02:53 +0000 |
| commit | 21006d40ac9ec7715bca2095451075a83773dc52 (patch) | |
| tree | a3015838890edfbb23387b5a3dcacb28a51b6e96 /docs | |
| parent | 51c9805c4bcca635bc6a854e4a246ebd4258f512 (diff) | |
| download | llvm-21006d40ac9ec7715bca2095451075a83773dc52.tar.gz llvm-21006d40ac9ec7715bca2095451075a83773dc52.tar.bz2 llvm-21006d40ac9ec7715bca2095451075a83773dc52.tar.xz | |
Representation of 'atomic load' and 'atomic store' in IR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137170 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/Atomics.html | 1 | ||||
| -rw-r--r-- | docs/LangRef.html | 47 |
2 files changed, 35 insertions, 13 deletions
diff --git a/docs/Atomics.html b/docs/Atomics.html index 92065a9b45..a7bfe18f7e 100644 --- a/docs/Atomics.html +++ b/docs/Atomics.html @@ -3,6 +3,7 @@ <html> <head> <title>LLVM Atomic Instructions and Concurrency Guide</title> + <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <link rel="stylesheet" href="llvm.css" type="text/css"> </head> <body> diff --git a/docs/LangRef.html b/docs/LangRef.html index 71212cc718..530be57d75 100644 --- a/docs/LangRef.html +++ b/docs/LangRef.html @@ -1583,8 +1583,10 @@ as if it writes to the relevant surrounding bytes. <div class="doc_text"> <p>Atomic instructions (<a href="#i_cmpxchg"><code>cmpxchg</code></a>, -<a href="#i_atomicrmw"><code>atomicrmw</code></a>, and -<a href="#i_fence"><code>fence</code></a>) take an ordering parameter +<a href="#i_atomicrmw"><code>atomicrmw</code></a>, +<a href="#i_fence"><code>fence</code></a>, +<a href="#i_load"><code>atomic load</code></a>, and +<a href="#i_load"><code>atomic store</code></a>) take an ordering parameter that determines which other atomic instructions on the same address they <i>synchronize with</i>. These semantics are borrowed from Java and C++0x, but are somewhat more colloquial. If these descriptions aren't precise enough, @@ -1592,11 +1594,7 @@ check those specs. <a href="#i_fence"><code>fence</code></a> instructions treat these orderings somewhat differently since they don't take an address. See that instruction's documentation for details.</p> -<!-- FIXME Note atomic load+store here once those get added. --> - <dl> -<!-- FIXME: unordered is intended to be used for atomic load and store; -it isn't allowed for any instruction yet. --> <dt><code>unordered</code></dt> <dd>The set of values that can be read is governed by the happens-before partial order. A value cannot be read unless some operation wrote it. @@ -4572,8 +4570,8 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <h5>Syntax:</h5> <pre> - <result> = load <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>] - <result> = volatile load <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>] + <result> = [volatile] load <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>] + <result> = atomic [volatile] load <ty>* <pointer> [singlethread] <ordering>, align <alignment> !<index> = !{ i32 1 } </pre> @@ -4588,6 +4586,19 @@ that the invoke/unwind semantics are likely to change in future versions.</p> number or order of execution of this <tt>load</tt> with other <a href="#volatile">volatile operations</a>.</p> +<p>If the <code>load</code> is marked as <code>atomic</code>, it takes an extra + <a href="#ordering">ordering</a> and optional <code>singlethread</code> + argument. The <code>release</code> and <code>acq_rel</code> orderings are + not valid on <code>load</code> instructions. Atomic loads produce <a + href="#memorymodel">defined</a> results when they may see multiple atomic + stores. The type of the pointee must be an integer type whose bit width + is a power of two greater than or equal to eight and less than or equal + to a target-specific size limit. <code>align</code> must be explicitly + specified on atomic loads, and the load has undefined behavior if the + alignment is not set to a value which is at least the size in bytes of + the pointee. <code>!nontemporal</code> does not have any defined semantics + for atomic loads.</p> + <p>The optional constant <tt>align</tt> argument specifies the alignment of the operation (that is, the alignment of the memory address). A value of 0 or an omitted <tt>align</tt> argument means that the operation has the preferential @@ -4631,8 +4642,8 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <h5>Syntax:</h5> <pre> - store <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>] <i>; yields {void}</i> - volatile store <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>] <i>; yields {void}</i> + [volatile] store <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>] <i>; yields {void}</i> + atomic [volatile] store <ty> <value>, <ty>* <pointer> [singlethread] <ordering>, align <alignment> <i>; yields {void}</i> </pre> <h5>Overview:</h5> @@ -4648,6 +4659,19 @@ that the invoke/unwind semantics are likely to change in future versions.</p> order of execution of this <tt>store</tt> with other <a href="#volatile">volatile operations</a>.</p> +<p>If the <code>store</code> is marked as <code>atomic</code>, it takes an extra + <a href="#ordering">ordering</a> and optional <code>singlethread</code> + argument. The <code>acquire</code> and <code>acq_rel</code> orderings aren't + valid on <code>store</code> instructions. Atomic loads produce <a + href="#memorymodel">defined</a> results when they may see multiple atomic + stores. The type of the pointee must be an integer type whose bit width + is a power of two greater than or equal to eight and less than or equal + to a target-specific size limit. <code>align</code> must be explicitly + specified on atomic stores, and the store has undefined behavior if the + alignment is not set to a value which is at least the size in bytes of + the pointee. <code>!nontemporal</code> does not have any defined semantics + for atomic stores.</p> + <p>The optional constant "align" argument specifies the alignment of the operation (that is, the alignment of the memory address). A value of 0 or an omitted "align" argument means that the operation has the preferential @@ -4730,9 +4754,6 @@ operations and/or fences.</p> specifies that the fence only synchronizes with other fences in the same thread. (This is useful for interacting with signal handlers.)</p> -<p>FIXME: This instruction is a work in progress; until it is finished, use - llvm.memory.barrier. - <h5>Example:</h5> <pre> fence acquire <i>; yields {void}</i> |