diff options
Diffstat (limited to 'docs/LangRef.html')
-rw-r--r-- | docs/LangRef.html | 107 |
1 files changed, 77 insertions, 30 deletions
diff --git a/docs/LangRef.html b/docs/LangRef.html index 946380e..13daa65 100644 --- a/docs/LangRef.html +++ b/docs/LangRef.html @@ -25,7 +25,6 @@ <li><a href="#linkage_private">'<tt>private</tt>' Linkage</a></li> <li><a href="#linkage_linker_private">'<tt>linker_private</tt>' Linkage</a></li> <li><a href="#linkage_linker_private_weak">'<tt>linker_private_weak</tt>' Linkage</a></li> - <li><a href="#linkage_linker_private_weak_def_auto">'<tt>linker_private_weak_def_auto</tt>' Linkage</a></li> <li><a href="#linkage_internal">'<tt>internal</tt>' Linkage</a></li> <li><a href="#linkage_available_externally">'<tt>available_externally</tt>' Linkage</a></li> <li><a href="#linkage_linkonce">'<tt>linkonce</tt>' Linkage</a></li> @@ -34,6 +33,7 @@ <li><a href="#linkage_appending">'<tt>appending</tt>' Linkage</a></li> <li><a href="#linkage_externweak">'<tt>extern_weak</tt>' Linkage</a></li> <li><a href="#linkage_linkonce_odr">'<tt>linkonce_odr</tt>' Linkage</a></li> + <li><a href="#linkage_linkonce_odr_auto_hide">'<tt>linkonce_odr_auto_hide</tt>' Linkage</a></li> <li><a href="#linkage_weak">'<tt>weak_odr</tt>' Linkage</a></li> <li><a href="#linkage_external">'<tt>external</tt>' Linkage</a></li> <li><a href="#linkage_dllimport">'<tt>dllimport</tt>' Linkage</a></li> @@ -103,6 +103,7 @@ <li><a href="#metadata">Metadata Nodes and Metadata Strings</a> <ol> <li><a href="#tbaa">'<tt>tbaa</tt>' Metadata</a></li> + <li><a href="#tbaa.struct">'<tt>tbaa.struct</tt>' Metadata</a></li> <li><a href="#fpmath">'<tt>fpmath</tt>' Metadata</a></li> <li><a href="#range">'<tt>range</tt>' Metadata</a></li> </ol> @@ -576,15 +577,6 @@ define i32 @main() { <i>; i32()* </i> linker. The symbols are removed by the linker from the final linked image (executable or dynamic library).</dd> - <dt><tt><b><a name="linkage_linker_private_weak_def_auto">linker_private_weak_def_auto</a></b></tt></dt> - <dd>Similar to "<tt>linker_private_weak</tt>", but it's known that the address - of the object is not taken. For instance, functions that had an inline - definition, but the compiler decided not to inline it. Note, - unlike <tt>linker_private</tt> and <tt>linker_private_weak</tt>, - <tt>linker_private_weak_def_auto</tt> may have only <tt>default</tt> - visibility. The symbols are removed by the linker from the final linked - image (executable or dynamic library).</dd> - <dt><tt><b><a name="linkage_internal">internal</a></b></tt></dt> <dd>Similar to private, but the value shows as a local symbol (<tt>STB_LOCAL</tt> in the case of ELF) in the object file. This @@ -653,6 +645,14 @@ define i32 @main() { <i>; i32()* </i> be merged with equivalent globals. These linkage types are otherwise the same as their non-<tt>odr</tt> versions.</dd> + <dt><tt><b><a name="linkage_linkonce_odr_auto_hide">linkonce_odr_auto_hide</a></b></tt></dt> + <dd>Similar to "<tt>linkonce_odr</tt>", but nothing in the translation unit + takes the address of this definition. For instance, functions that had an + inline definition, but the compiler decided not to inline it. + <tt>linkonce_odr_auto_hide</tt> may have only <tt>default</tt> visibility. + The symbols are removed by the linker from the final linked image + (executable or dynamic library).</dd> + <dt><tt><b><a name="linkage_external">external</a></b></tt></dt> <dd>If none of the above identifiers are used, the global is externally visible, meaning that it participates in linkage and can be used to @@ -1107,9 +1107,9 @@ declare signext i8 @returns_signed_char() <dd>This indicates that the pointer parameter specifies the address of a structure that is the return value of the function in the source program. This pointer must be guaranteed by the caller to be valid: loads and - stores to the structure may be assumed by the callee to not to trap. This - may only be applied to the first parameter. This is not a valid attribute - for return values. </dd> + stores to the structure may be assumed by the callee to not to trap and + to be properly aligned. This may only be applied to the first parameter. + This is not a valid attribute for return values. </dd> <dt><tt><b><a name="noalias">noalias</a></b></tt></dt> <dd>This indicates that pointer values @@ -1208,13 +1208,6 @@ define void @f() optsize { ... } may make calls to the function faster, at the cost of extra program startup time if the function is not called during program startup.</dd> - <dt><tt><b>ia_nsdialect</b></tt></dt> - <dd>This attribute indicates the associated inline assembly call is using a - non-standard assembly dialect. The standard dialect is ATT, which is - assumed when this attribute is not present. When present, the dialect - is assumed to be Intel. Currently, ATT and Intel are the only supported - dialects.</dd> - <dt><tt><b>inlinehint</b></tt></dt> <dd>This attribute indicates that the source code contained a hint that inlining this function is desirable (such as the "inline" keyword in C/C++). It @@ -1371,11 +1364,13 @@ target datalayout = "<i>layout specification</i>" 8-bits. If omitted, the natural stack alignment defaults to "unspecified", which does not prevent any alignment promotions.</dd> - <dt><tt>p:<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt> + <dt><tt>p[n]:<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt> <dd>This specifies the <i>size</i> of a pointer and its <i>abi</i> and - <i>preferred</i> alignments. All sizes are in bits. Specifying - the <i>pref</i> alignment is optional. If omitted, the - preceding <tt>:</tt> should be omitted too.</dd> + <i>preferred</i> alignments for address space <i>n</i>. All sizes are in + bits. Specifying the <i>pref</i> alignment is optional. If omitted, the + preceding <tt>:</tt> should be omitted too. The address space, + <i>n</i> is optional, and if not specified, denotes the default address + space 0. The value of <i>n</i> must be in the range [1,2^23).</dd> <dt><tt>i<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt> <dd>This specifies the alignment for an integer type of a given bit @@ -1416,6 +1411,10 @@ target datalayout = "<i>layout specification</i>" <ul> <li><tt>E</tt> - big endian</li> <li><tt>p:64:64:64</tt> - 64-bit pointers with 64-bit alignment</li> + <li><tt>p1:32:32:32</tt> - 32-bit pointers with 32-bit alignment for + address space 1</li> + <li><tt>p2:16:32:32</tt> - 16-bit pointers with 32-bit alignment for + address space 2</li> <li><tt>i1:8:8</tt> - i1 is 8-bit (byte) aligned</li> <li><tt>i8:8:8</tt> - i8 is 8-bit (byte) aligned</li> <li><tt>i16:16:16</tt> - i16 is 16-bit aligned</li> @@ -2111,7 +2110,7 @@ in signal handlers).</p> <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 inserted - as defined by the TargetData string in the module, which is required to match + as defined by the DataLayout string in the module, which is required to match what the underlying code generator expects.</p> <p>Structures can either be "literal" or "identified". A literal structure is @@ -2902,8 +2901,18 @@ call void asm sideeffect "eieio", ""() call void asm alignstack "eieio", ""() </pre> -<p>If both keywords appear the '<tt>sideeffect</tt>' keyword must come - first.</p> +<p>Inline asms also support using non-standard assembly dialects. The assumed + dialect is ATT. When the '<tt>inteldialect</tt>' keyword is present, the + inline asm is using the Intel dialect. Currently, ATT and Intel are the + only supported dialects. An example is:</p> + +<pre class="doc_code"> +call void asm inteldialect "eieio", ""() +</pre> + +<p>If multiple keywords appear the '<tt>sideeffect</tt>' keyword must come + first, the '<tt>alignstack</tt>' keyword second and the + '<tt>inteldialect</tt>' keyword last.</p> <!-- <p>TODO: The format of the asm and constraints string still need to be @@ -3050,6 +3059,44 @@ call void @llvm.dbg.value(metadata !24, i64 0, metadata !25) <!-- _______________________________________________________________________ --> <h4> + <a name="tbaa.struct">'<tt>tbaa.struct</tt>' Metadata</a> +</h4> + +<div> + +<p>The <a href="#int_memcpy"><tt>llvm.memcpy</tt></a> is often used to implement +aggregate assignment operations in C and similar languages, however it is +defined to copy a contiguous region of memory, which is more than strictly +necessary for aggregate types which contain holes due to padding. Also, it +doesn't contain any TBAA information about the fields of the aggregate.</p> + +<p><tt>!tbaa.struct</tt> metadata can describe which memory subregions in a memcpy +are padding and what the TBAA tags of the struct are.</p> + +<p>The current metadata format is very simple. <tt>!tbaa.struct</tt> metadata nodes + are a list of operands which are in conceptual groups of three. For each + group of three, the first operand gives the byte offset of a field in bytes, + the second gives its size in bytes, and the third gives its + tbaa tag. e.g.:</p> + +<div class="doc_code"> +<pre> +!4 = metadata !{ i64 0, i64 4, metadata !1, i64 8, i64 4, metadata !2 } +</pre> +</div> + +<p>This describes a struct with two fields. The first is at offset 0 bytes + with size 4 bytes, and has tbaa tag !1. The second is at offset 8 bytes + and has size 4 bytes and has tbaa tag !2.</p> + +<p>Note that the fields need not be contiguous. In this example, there is a + 4 byte gap between the two fields. This gap represents padding which + does not carry useful data and need not be preserved.</p> + +</div> + +<!-- _______________________________________________________________________ --> +<h4> <a name="fpmath">'<tt>fpmath</tt>' Metadata</a> </h4> @@ -5013,7 +5060,7 @@ IfUnequal: <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 + omitted <tt>align</tt> argument means that the operation has the abi alignment for the target. It is the responsibility of the code emitter to ensure that the alignment information is correct. Overestimating the alignment results in undefined behavior. Underestimating the alignment may @@ -5094,7 +5141,7 @@ IfUnequal: <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 + omitted "align" argument means that the operation has the abi alignment for the target. It is the responsibility of the code emitter to ensure that the alignment information is correct. Overestimating the alignment results in an undefined behavior. Underestimating the alignment may @@ -8722,7 +8769,7 @@ codegen.</p> <a href="mailto:sabre@nondot.org">Chris Lattner</a><br> <a href="http://llvm.org/">The LLVM Compiler Infrastructure</a><br> - Last modified: $Date: 2012-08-10 02:00:22 +0200 (Fri, 10 Aug 2012) $ + Last modified: $Date: 2012-10-29 15:12:44 +0100 (Mon, 29 Oct 2012) $ </address> </body> |