X-Git-Url: http://demsky.eecs.uci.edu/git/?a=blobdiff_plain;f=docs%2FLangRef.html;h=15ecf86d4f86142bf172c97dd2a2abfe53b3218a;hb=4962e6143186f6168f5d0ee979bf047651a13124;hp=9fcdee883c30021853a91425990a3b5fb64f71c4;hpb=fbbee8d7f967b72c5ec3105ef1b21e8a115a8b78;p=oota-llvm.git diff --git a/docs/LangRef.html b/docs/LangRef.html index 9fcdee883c3..15ecf86d4f8 100644 --- a/docs/LangRef.html +++ b/docs/LangRef.html @@ -24,6 +24,8 @@
+%x = add i32 1, %x-
because the definition of %x does not dominate all of its uses. The LLVM infrastructure provides a verification pass that may be used to verify @@ -428,29 +436,23 @@
The easy way:
-+%result = mul i32 %X, 8-
After strength reduction:
-+%result = shl i32 %X, i8 3-
And the hard way:
-+%0 = add i32 %X, %X ; yields {i32}:%0 %1 = add i32 %0, %0 ; yields {i32}:%1 %result = add i32 %1, %1-
This last way of multiplying %X by 8 illustrates several important lexical features of LLVM:
@@ -489,28 +491,27 @@ forward declarations, and merges symbol table entries. Here is an example of the "hello world" module: --; Declare the string constant as a global constant. -@.LC0 = internal constant [13 x i8] c"hello world\0A\00" ; [13 x i8]* ++; Declare the string constant as a global constant. +@.LC0 = internal constant [13 x i8] c"hello world\0A\00" ; [13 x i8]* -; External declaration of the puts function -declare i32 @puts(i8 *) ; i32(i8 *)* +; External declaration of the puts function +declare i32 @puts(i8*) ; i32 (i8*)* ; Definition of main function -define i32 @main() { ; i32()* - ; Convert [13 x i8]* to i8 *... - %cast210 = getelementptr [13 x i8]* @.LC0, i64 0, i64 0 ; i8 * +define i32 @main() { ; i32()* + ; Convert [13 x i8]* to i8 *... + %cast210 = getelementptr [13 x i8]* @.LC0, i64 0, i64 0 ; i8* - ; Call puts function to write out the string to stdout. - call i32 @puts(i8 * %cast210) ; i32 - ret i32 0-
} + ; Call puts function to write out the string to stdout. + call i32 @puts(i8* %cast210) ; i32 + ret i32 0 +} ; Named metadata !1 = metadata !{i32 41} !foo = !{!1, null}
This example is made up of a global variable named ".LC0", an external declaration of the "puts" function, @@ -538,20 +539,33 @@ define i32 @main() { ; i32()*
+%mytype = type { %mytype*, i32 }-
You may give a name to any type except - "void". Type name aliases may be used anywhere a type + "void". Type name aliases may be used anywhere a type is expected with the syntax "%mytype".
Note that type names are aliases for the structural type that they indicate, @@ -814,6 +846,13 @@ define i32 @main() { ; i32()* region of memory, and all memory objects in LLVM are accessed through pointers.
+Global variables can be marked with unnamed_addr which indicates + that the address is not significant, only the content. Constants marked + like this can be merged with other constants if they have the same + initializer. Note that a constant with significant address can + be merged with a unnamed_addr constant, the result being a + constant whose address is significant.
+A global variable may be declared to reside in a target-specific numbered address space. For targets that support them, address spaces may affect how optimizations are performed and/or what target instructions are used to @@ -823,20 +862,22 @@ define i32 @main() { ; i32()*
LLVM allows an explicit section to be specified for globals. If the target supports it, it will emit globals to the section specified.
-An explicit alignment may be specified for a global. If not present, or if - the alignment is set to zero, the alignment of the global is set by the - target to whatever it feels convenient. If an explicit alignment is - specified, the global is forced to have at least that much alignment. All - alignments must be a power of 2.
+An explicit alignment may be specified for a global, which must be a power + of 2. If not present, or if the alignment is set to zero, the alignment of + the global is set by the target to whatever it feels convenient. If an + explicit alignment is specified, the global is forced to have exactly that + alignment. Targets and optimizers are not allowed to over-align the global + if the global has an assigned section. In this case, the extra alignment + could be observable: for example, code could assume that the globals are + densely packed in their section and try to iterate over them as an array, + alignment padding would break this iteration.
For example, the following defines a global in a numbered address space with an initializer, section, and alignment:
-+@G = addrspace(5) constant float 1.0, section "foo", align 4-
LLVM function definitions consist of the "define" keyword, an optional linkage type, an optional visibility style, an optional - calling convention, a return type, an optional + calling convention, + an optional unnamed_addr attribute, a return type, an optional parameter attribute for the return type, a function name, a (possibly empty) argument list (each with optional parameter attributes), optional @@ -862,7 +904,8 @@ define i32 @main() { ; i32()*
LLVM function declarations consist of the "declare" keyword, an optional linkage type, an optional visibility style, an optional - calling convention, a return type, an optional + calling convention, + an optional unnamed_addr attribute, a return type, an optional parameter attribute for the return type, a function name, a possibly empty list of arguments, an optional alignment, and an optional garbage collector name.
@@ -888,16 +931,17 @@ define i32 @main() { ; i32()* specified, the function is forced to have at least that much alignment. All alignments must be a power of 2. +If the unnamed_addr attribute is given, the address is know to not + be significant and two identical functions can be merged
. ++define [linkage] [visibility] [cconv] [ret attrs] <ResultType> @<FunctionName> ([argument list]) [fn Attrs] [section "name"] [align N] [gc] { ... }-
+@<Name> = alias [Linkage] [Visibility] <AliaseeTy> @<Aliasee>-
Named metadata is a collection of metadata. Metadata - nodes (but not metadata strings) and null are the only valid operands for + nodes (but not metadata strings) are the only valid operands for a named metadata.
++; Some unnamed metadata nodes, which are referenced by the named metadata. +!0 = metadata !{metadata !"zero"} !1 = metadata !{metadata !"one"} -!name = !{null, !1} +!2 = metadata !{metadata !"two"} +; A named metadata. +!name = !{!0, !1, !2}-
+declare i32 @printf(i8* noalias nocapture, ...) declare i32 @atoi(i8 zeroext) declare signext i8 @returns_signed_char()-
Note that any attributes for the function result (nounwind, readonly) come immediately after the argument list.
@@ -975,13 +1017,15 @@ declare signext i8 @returns_signed_char()This indicates that the pointer parameter should really be passed by + value to the function. The attribute implies that a hidden copy of the + pointee is made between the caller and the callee, so the callee is unable to modify the value in the callee. This attribute is only valid on LLVM pointer arguments. It is generally used to pass structs and arrays by @@ -1000,12 +1045,15 @@ declare signext i8 @returns_signed_char() to belong to the caller not the callee (for example, readonly functions should not write to byval parameters). This is not a valid attribute for return - values. The byval attribute also supports specifying an alignment with - the align attribute. This has a target-specific effect on the code - generator that usually indicates a desired alignment for the synthesized - stack slot.
The byval attribute also supports specifying an alignment with + the align attribute. It indicates the alignment of the stack slot to + form and the known alignment of the pointer specified to the call site. If + the alignment is not specified, then the code generator makes a + target-specific assumption.
+ +Each function may specify a garbage collector name, which is simply a string:
-+define void @f() gc "name" { ... }-
The compiler declares the supported values of name. Specifying a collector which will cause the compiler to alter its output in order to @@ -1073,14 +1131,12 @@ define void @f() gc "name" { ... }
Function attributes are simple keywords that follow the type specified. If multiple attributes are needed, they are space separated. For example:
-+define void @f() noinline { ... } define void @f() alwaysinline { ... } define void @f() alwaysinline optsize { ... } define void @f() optsize { ... }-
+module asm "inline asm code goes here" module asm "more can go here"-
The strings can contain any character by escaping non-printable characters. The escape sequence used is simply "\xx" where "xx" is the two digit hex code @@ -1214,11 +1276,9 @@ module asm "more can go here" data is to be laid out in memory. The syntax for the data layout is simply:
-+target datalayout = "layout specification"-
The layout specification consists of a list of specifications separated by the minus sign character ('-'). Each specification starts with @@ -1251,8 +1311,10 @@ target datalayout = "layout specification"
When constructing the data layout for a given target, LLVM starts with a - default set of specifications which are then (possibly) overriden by the + default set of specifications which are then (possibly) overridden by the specifications in the datalayout keyword. The default specifications are given in this list:
@@ -1328,34 +1390,46 @@ is undefined. Pointer values are associated with address ranges according to the following rules:A pointer value is based on another pointer value according + to the following rules:
+ +Note that this definition of "based" is intentionally + similar to the definition of "based" in C99, though it is + slightly weaker.
LLVM IR does not associate types with memory. The result type of a load merely indicates the size and alignment of the memory from which to load, as well as the -interpretation of the value. The first operand of a +interpretation of the value. The first operand type of a store similarly only indicates the size and alignment of the store.
@@ -1367,6 +1441,24 @@ to implement type-based alias analysis. + + + +Certain memory accesses, such as loads, stores, and llvm.memcpys may be marked volatile. +The optimizers must not change the number of volatile operations or change their +order of execution relative to other volatile operations. The optimizers +may change the order of volatile operations relative to non-volatile +operations. This is not Java's "volatile" and has no cross-thread +synchronization behavior.
+ +The x86mmx type represents a value held in an MMX register on an x86 machine. The operations allowed on it are quite limited: parameters and return values, load and store, and bitcast. User-specified MMX instructions are represented as intrinsic or asm calls with arguments and/or results of this type. There are no arrays, vectors or constants of this type.
+ ++ x86mmx ++ +
Aggregate Types are a subset of derived types that can contain multiple member types. Arrays, - structs, vectors and - unions are aggregate types.
- - + structs, and vectors are + aggregate types. @@ -1650,9 +1755,7 @@ ClassificationsThe function type can be thought of as a function signature. It consists of a return type and a list of formal parameter types. The return type of a - function type is a scalar type, a void type, a struct type, or a union - type. If the return type is a struct type then all struct elements must be - of first class types, and the struct must have at least one element.
+ function type is a first class type or a void type.@@ -1664,7 +1767,7 @@ Classifications which indicates that the function takes a variable number of arguments. Variable argument functions can access their arguments with the variable argument handling intrinsic - functions. '<returntype>' is a any type except + functions. '<returntype>' is any type except label.Examples:
@@ -1674,12 +1777,11 @@ Classificationsfunction taking an i32, returning an i32
A union type describes an object with size and alignment suitable for - an object of any one of a given set of types (also known as an "untagged" - union). It is similar in concept and usage to a - struct, except that all members of the union - have an offset of zero. The elements of a union may be any type that has a - size. Unions must have at least one member - empty unions are not allowed. -
- -The size of the union as a whole will be the size of its largest member, - and the alignment requirements of the union as a whole will be the largest - alignment requirement of any member.
- -Union members are accessed using 'load and - 'store' by getting a pointer to a field with - the 'getelementptr' instruction. - Since all members are at offset zero, the getelementptr instruction does - not affect the address, only the type of the resulting pointer.
- -- union { <type list> } -- -
union { i32, i32*, float } | -A union of three types: an i32, a pointer to - an i32, and a float. | -
- union { float, i32 (i32) * } | -A union, where the first element is a float and the - second element is a pointer to a - function that takes an i32, returning - an i32. | -
The number of elements is a constant integer value; elementtype may be any - integer or floating point type.
+The number of elements is a constant integer value larger than 0; elementtype + may be any integer or floating point type. Vectors of size zero are not + allowed, and pointers are not allowed as the element type.