</div>
<!-- ======================================================================= -->
-<div class="doc_subsection">
+<h3>
<a name="ordering">Atomic Memory Ordering Constraints</a>
-</div>
+</h3>
-<div class="doc_text">
+<div>
<p>Atomic instructions (<a href="#i_cmpxchg"><code>cmpxchg</code></a>,
<a href="#i_atomicrmw"><code>atomicrmw</code></a>,
<p>Structures may optionally be "packed" structures, which indicate that the
alignment of the struct is one byte, and that there is no padding between
- the elements. In non-packed structs, padding between field types is defined
- by the target data string to match the underlying processor.</p>
-
-<p>Structures can either be "anonymous" or "named". An anonymous structure is
- defined inline with other types (e.g. <tt>{i32, i32}*</tt>) and a named types
- are always defined at the top level with a name. Anonmyous types are uniqued
- by their contents and can never be recursive since there is no way to write
- one. Named types can be recursive.
+ the elements. In non-packed structs, padding between field types is inserted
+ as defined by the TargetData string in the module, which is required to match
+ what the underlying processor expects.</p>
+
+<p>Structures can either be "literal" or "identified". A literal structure is
+ defined inline with other types (e.g. <tt>{i32, i32}*</tt>) whereas identified
+ types are always defined at the top level with a name. Literal types are
+ uniqued by their contents and can never be recursive or opaque since there is
+ no way to write one. Identified types can be recursive, can be opaqued, and are
+ never uniqued.
</p>
<h5>Syntax:</h5>
<pre>
- %T1 = type { <type list> } <i>; Named normal struct type</i>
- %T2 = type <{ <type list> }> <i>; Named packed struct type</i>
+ %T1 = type { <type list> } <i>; Identified normal struct type</i>
+ %T2 = type <{ <type list> }> <i>; Identified packed struct type</i>
</pre>
<h5>Examples:</h5>
<h5>Syntax:</h5>
<pre>
- <result> = [volatile] load <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>]
- <result> = atomic [volatile] load <ty>* <pointer> [singlethread] <ordering>, align <alignment>
+ <result> = load [volatile] <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>]
+ <result> = load atomic [volatile] <ty>* <pointer> [singlethread] <ordering>, align <alignment>
!<index> = !{ i32 1 }
</pre>
<h5>Syntax:</h5>
<pre>
- [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>
+ store [volatile] <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>] <i>; yields {void}</i>
+ store atomic [volatile] <ty> <value>, <ty>* <pointer> [singlethread] <ordering>, align <alignment> <i>; yields {void}</i>
</pre>
<h5>Overview:</h5>
</div>
<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="i_fence">'<tt>fence</tt>'
-Instruction</a> </div>
+<h4>
+<a name="i_fence">'<tt>fence</tt>' Instruction</a>
+</h4>
-<div class="doc_text">
+<div>
<h5>Syntax:</h5>
<pre>
</div>
<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="i_cmpxchg">'<tt>cmpxchg</tt>'
-Instruction</a> </div>
+<h4>
+<a name="i_cmpxchg">'<tt>cmpxchg</tt>' Instruction</a>
+</h4>
-<div class="doc_text">
+<div>
<h5>Syntax:</h5>
<pre>
- [volatile] cmpxchg <ty>* <pointer>, <ty> <cmp>, <ty> <new> [singlethread] <ordering> <i>; yields {ty}</i>
+ cmpxchg [volatile] <ty>* <pointer>, <ty> <cmp>, <ty> <new> [singlethread] <ordering> <i>; yields {ty}</i>
</pre>
<h5>Overview:</h5>
</div>
<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="i_atomicrmw">'<tt>atomicrmw</tt>'
-Instruction</a> </div>
+<h4>
+<a name="i_atomicrmw">'<tt>atomicrmw</tt>' Instruction</a>
+</h4>
-<div class="doc_text">
+<div>
<h5>Syntax:</h5>
<pre>
- [volatile] atomicrmw <operation> <ty>* <pointer>, <ty> <value> [singlethread] <ordering> <i>; yields {ty}</i>
+ atomicrmw [volatile] <operation> <ty>* <pointer>, <ty> <value> [singlethread] <ordering> <i>; yields {ty}</i>
</pre>
<h5>Overview:</h5>
When indexing into a (optionally packed) structure, only <tt>i32</tt>
integer <b>constants</b> are allowed. When indexing into an array, pointer
or vector, integers of any width are allowed, and they are not required to be
- constant.</p>
+ constant. These integers are treated as signed values where relevant.</p>
<p>For example, let's consider a C code fragment and how it gets compiled to
LLVM:</p>
base pointer is not an <i>in bounds</i> address of an allocated object,
or if any of the addresses that would be formed by successive addition of
the offsets implied by the indices to the base address with infinitely
- precise arithmetic are not an <i>in bounds</i> address of that allocated
- object. The <i>in bounds</i> addresses for an allocated object are all
- the addresses that point into the object, plus the address one byte past
- the end.</p>
+ precise signed arithmetic are not an <i>in bounds</i> address of that
+ allocated object. The <i>in bounds</i> addresses for an allocated object
+ are all the addresses that point into the object, plus the address one
+ byte past the end.</p>
<p>If the <tt>inbounds</tt> keyword is not present, the offsets are added to
- the base address with silently-wrapping two's complement arithmetic, and
- the result value of the <tt>getelementptr</tt> may be outside the object
- pointed to by the base pointer. The result value may not necessarily be
- used to access memory though, even if it happens to point into allocated
- storage. See the <a href="#pointeraliasing">Pointer Aliasing Rules</a>
- section for more information.</p>
+ the base address with silently-wrapping two's complement arithmetic. If the
+ offsets have a different width from the pointer, they are sign-extended or
+ truncated to the width of the pointer. The result value of the
+ <tt>getelementptr</tt> may be outside the object pointed to by the base
+ pointer. The result value may not necessarily be used to access memory
+ though, even if it happens to point into allocated storage. See the
+ <a href="#pointeraliasing">Pointer Aliasing Rules</a> section for more
+ information.</p>
<p>The getelementptr instruction is often confusing. For some more insight into
how it works, see <a href="GetElementPtr.html">the getelementptr FAQ</a>.</p>
<resultval> = landingpad <somety> personality <type> <pers_fn> cleanup <clause>*
<clause> := catch <type> <value>
- <clause> := filter <type> <value> {, <type> <value>}*
+ <clause> := filter <array constant type> <array constant>
</pre>
<h5>Overview:</h5>
<tt>cleanup</tt> flag indicates that the landing pad block is a cleanup.</p>
<p>A <tt>clause</tt> begins with the clause type — <tt>catch</tt>
- or <tt>filter</tt> — and contains a list of global variables
- representing the "types" that may be caught or filtered respectively. The
- '<tt>landingpad</tt>' instruction must contain <em>at least</em>
+ or <tt>filter</tt> — and contains the global variable representing the
+ "type" that may be caught or filtered respectively. Unlike the
+ <tt>catch</tt> clause, the <tt>filter</tt> clause takes an array constant as
+ its argument. Use "<tt>[0 x i8**] undef</tt>" for a filter which cannot
+ throw. The '<tt>landingpad</tt>' instruction must contain <em>at least</em>
one <tt>clause</tt> or the <tt>cleanup</tt> flag.</p>
<h5>Semantics:</h5>
catch i8** @_ZTIi
;; A landing pad that is a cleanup.
%res = landingpad { i8*, i32 } personality i32 (...)* @__gxx_personality_v0
- cleanup
+ cleanup
;; A landing pad which can catch an integer and can only throw a double.
%res = landingpad { i8*, i32 } personality i32 (...)* @__gxx_personality_v0
catch i8** @_ZTIi
- filter i8** @_ZTId
+ filter [1 x i8**] [@_ZTId]
</pre>
</div>
projects / oota-llvm.git / blobdiff