X-Git-Url: http://plrg.eecs.uci.edu/git/?a=blobdiff_plain;f=docs%2FLangRef.html;h=4c635d3a5aadc4951faba7f29599b28db2f37125;hb=1005bc5068345e28826a32cc081dd4667af978ff;hp=7d8f14bca6b3035308128c606740c50272f99573;hpb=ff23535df64ffdfa73540669ea642f6b84221217;p=oota-llvm.git diff --git a/docs/LangRef.html b/docs/LangRef.html index 7d8f14bca6b..4c635d3a5aa 100644 --- a/docs/LangRef.html +++ b/docs/LangRef.html @@ -370,11 +370,9 @@ what is considered 'well formed'. For example, the following instruction is syntactically okay, but not well formed:

-
-
+
 %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 @@ -437,29 +435,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:

@@ -498,8 +490,7 @@ 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]*
 
@@ -519,7 +510,6 @@ define i32 @main() {                                        ; i32()* 
 !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, @@ -793,11 +783,9 @@ define i32 @main() { ; i32()* it easier to read the IR and make the IR more condensed (particularly when recursive types are involved). An example of a name specification is:

-
-
+
 %mytype = type { %mytype*, i32 }
 
-

You may give a name to any type except "void". Type name aliases may be used anywhere a type @@ -869,11 +857,9 @@ define i32 @main() { ; i32()*

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
 
-
@@ -926,15 +912,13 @@ define i32 @main() { ; i32()* alignments must be a power of 2.

Syntax:
-
-
+
 define [linkage] [visibility]
        [cconv] [ret attrs]
        <ResultType> @<FunctionName> ([argument list])
        [fn Attrs] [section "name"] [align N]
        [gc] { ... }
 
-
@@ -951,11 +935,9 @@ define [linkage] [visibility] optional visibility style.

Syntax:
-
-
+
 @<Name> = alias [Linkage] [Visibility] <AliaseeTy> @<Aliasee>
 
-
@@ -971,12 +953,12 @@ define [linkage] [visibility] a named metadata.

Syntax:
-
-
+
+; An unnamed metadata node, which is referenced by the named metadata.
 !1 = metadata !{metadata !"one"}
+; A named metadata.
 !name = !{null, !1}
 
-
@@ -996,13 +978,11 @@ define [linkage] [visibility] multiple parameter attributes are needed, they are space separated. For example:

-
-
+
 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.

@@ -1053,11 +1033,24 @@ declare signext i8 @returns_signed_char()
noalias
This indicates that pointer values based on the argument or return - value do not alias pointer values which are not based on it. + value do not alias pointer values which are not based on it, + ignoring certain "irrelevant" dependencies. + For a call to the parent function, dependencies between memory + references from before or after the call and from those during the call + are "irrelevant" to the noalias keyword for the arguments and + return value used in that call. The caller shares the responsibility with the callee for ensuring that these requirements are met. For further details, please see the discussion of the NoAlias response in - alias analysis.
+ alias analysis.
+
+ Note that this definition of noalias is intentionally + similar to the definition of restrict in C99 for function + arguments, though it is slightly weaker. +
+ For function return values, C99's restrict is not meaningful, + while LLVM's noalias is. +
nocapture
This indicates that the callee does not make any copies of the pointer @@ -1082,11 +1075,9 @@ declare signext i8 @returns_signed_char()

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 @@ -1109,14 +1100,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 { ... }
 
-
alignstack(<n>)
@@ -1134,15 +1123,21 @@ define void @f() optsize { ... } this function is desirable (such as the "inline" keyword in C/C++). It is just a hint; it imposes no requirements on the inliner.
+
naked
+
This attribute disables prologue / epilogue emission for the function. + This can have very system-specific consequences.
+ +
noimplicitfloat
+
This attributes disables implicit floating point instructions.
+
noinline
This attribute indicates that the inliner should never inline this function in any situation. This attribute may not be used together with the alwaysinline attribute.
-
optsize
-
This attribute suggests that optimization passes and code generator passes - make choices that keep the code size of this function low, and otherwise - do optimizations specifically to reduce code size.
+
noredzone
+
This attribute indicates that the code generator should not use a red + zone, even if the target-specific ABI normally permits it.
noreturn
This function attribute indicates that the function never returns @@ -1154,6 +1149,11 @@ define void @f() optsize { ... } unwind or exceptional control flow. If the function does unwind, its runtime behavior is undefined.
+
optsize
+
This attribute suggests that optimization passes and code generator passes + make choices that keep the code size of this function low, and otherwise + do optimizations specifically to reduce code size.
+
readnone
This attribute indicates that the function computes its result (or decides to unwind an exception) based strictly on its arguments, without @@ -1196,17 +1196,6 @@ define void @f() optsize { ... } function that doesn't have an sspreq attribute or which has an ssp attribute, then the resulting function will have an sspreq attribute.
- -
noredzone
-
This attribute indicates that the code generator should not use a red - zone, even if the target-specific ABI normally permits it.
- -
noimplicitfloat
-
This attributes disables implicit floating point instructions.
- -
naked
-
This attribute disables prologue / epilogue emission for the function. - This can have very system-specific consequences.
@@ -1223,12 +1212,10 @@ define void @f() optsize { ... } concatenated by LLVM and treated as a single unit, but may be separated in the .ll file if desired. The syntax is very simple:

-
-
+
 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 @@ -1250,11 +1237,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 @@ -1650,8 +1635,6 @@ Classifications - -

Array Type
@@ -2185,13 +2168,11 @@ Classifications have pointer type. For example, the following is a legal LLVM file:

-
-
+
 @X = global i32 17
 @Y = global i32 42
 @Z = global [2 x i32*] [ i32* @X, i32* @Y ]
 
-
@@ -2210,8 +2191,7 @@ Classifications surprising) transformations that are valid (in pseudo IR):

-
-
+
   %A = add %X, undef
   %B = sub %X, undef
   %C = xor %X, undef
@@ -2220,13 +2200,11 @@ Safe:
   %B = undef
   %C = undef
 
-

This is safe because all of the output bits are affected by the undef bits. Any output bit can have a zero or one depending on the input bits.

-
-
+
   %A = or %X, undef
   %B = and %X, undef
 Safe:
@@ -2236,7 +2214,6 @@ Unsafe:
   %A = undef
   %B = undef
 
-

These logical operations have bits that are not always affected by the input. For example, if "%X" has a zero bit, then the output of the 'and' operation will @@ -2247,8 +2224,7 @@ optimize the and to 0. Likewise, it is safe to assume that all the bits of the undef operand to the or could be set, allowing the or to be folded to -1.

-
-
+
   %A = select undef, %X, %Y
   %B = select undef, 42, %Y
   %C = select %X, %Y, undef
@@ -2261,7 +2237,6 @@ Unsafe:
   %B = undef
   %C = undef
 
-

This set of examples show that undefined select (and conditional branch) conditions can go "either way" but they have to come from one of the two @@ -2271,8 +2246,7 @@ the optimizer is allowed to assume that the undef operand could be the same as %Y, allowing the whole select to be eliminated.

-
-
+
   %A = xor undef, undef
 
   %B = undef
@@ -2290,7 +2264,6 @@ Safe:
   %E = undef
   %F = undef
 
-

This example points out that two undef operands are not necessarily the same. This can be surprising to people (and also matches C semantics) where they @@ -2303,15 +2276,13 @@ so the value is not necessarily consistent over time. In fact, %A and %C need to have the same semantics or the core LLVM "replace all uses with" concept would not hold.

-
-
+
   %A = fdiv undef, %X
   %B = fdiv %X, undef
 Safe:
   %A = undef
 b: unreachable
 
-

These examples show the crucial difference between an undefined value and undefined behavior. An undefined value (like undef) is @@ -2326,15 +2297,13 @@ it: since the undefined operation "can't happen", the optimizer can assume that it occurs in dead code.

-
-
+
 a:  store undef -> %X
 b:  store %X -> undef
 Safe:
 a: <deleted>
 b: unreachable
 
-

These examples reiterate the fdiv example: a store "of" an undefined value can be assumed to not have any effect: we can assume that the value is @@ -2360,7 +2329,6 @@ has undefined behavior.

Trap value behavior is defined in terms of value dependence:

-

-

Whenever a trap value is generated, all values which depend on it evaluate to trap. If they have side effects, the evoke their side effects as if each @@ -2412,8 +2380,7 @@ has undefined behavior.

Here are some examples:

-
-
+
 entry:
   %trap = sub nuw i32 0, 1           ; Results in a trap value.
   %still_trap = and i32 %trap, 0     ; Whereas (and i32 undef, 0) would return 0.
@@ -2448,7 +2415,6 @@ end:
                                      ; so this is defined (ignoring earlier
                                      ; undefined behavior in this example).
 
-
@@ -2499,13 +2465,11 @@ end:
zext (CST to TYPE)
Zero extend a constant to another type. The bit size of CST must be - smaller or equal to the bit size of TYPE. Both types must be - integers.
+ smaller than the bit size of TYPE. Both types must be integers.
sext (CST to TYPE)
Sign extend a constant to another type. The bit size of CST must be - smaller or equal to the bit size of TYPE. Both types must be - integers.
+ smaller than the bit size of TYPE. Both types must be integers.
fptrunc (CST to TYPE)
Truncate a floating point constant to another floating point type. The @@ -2632,31 +2596,25 @@ end: containing the asm needs to align its stack conservatively. An example inline assembler expression is:

-
-
+
 i32 (i32) asm "bswap $0", "=r,r"
 
-

Inline assembler expressions may only be used as the callee operand of a call instruction. Thus, typically we have:

-
-
+
 %X = call i32 asm "bswap $0", "=r,r"(i32 %Y)
 
-

Inline asms with side effects not visible in the constraint list must be marked as having side effects. This is done through the use of the 'sideeffect' keyword, like so:

-
-
+
 call void asm sideeffect "eieio", ""()
 
-

In some cases inline asms will contain code that will not work unless the stack is aligned in some way, such as calls or SSE instructions on x86, @@ -2665,11 +2623,9 @@ call void asm sideeffect "eieio", ""() contain and should generate its usual stack alignment code in the prologue if the 'alignstack' keyword is present:

-
-
+
 call void asm alignstack "eieio", ""()
 
-

If both keywords appear the 'sideeffect' keyword must come first.

@@ -2693,13 +2649,11 @@ call void asm alignstack "eieio", ""() front-end to correlate backend errors that occur with inline asm back to the source code that produced it. For example:

-
-
+
 call void asm sideeffect "something bad", ""(), !srcloc !42
 ...
 !42 = !{ i32 1234567 }
 
-

It is up to the front-end to make sense of the magic numbers it places in the IR.

@@ -2734,22 +2688,18 @@ call void asm sideeffect "something bad", ""(), !srcloc !42 example: "!foo = metadata !{!4, !3}".

Metadata can be used as function arguments. Here llvm.dbg.value - function is using two metadata arguments. + function is using two metadata arguments.

-
-
+     
        call void @llvm.dbg.value(metadata !24, i64 0, metadata !25)
      
-

Metadata can be attached with an instruction. Here metadata !21 is - attached with add instruction using !dbg identifier. + attached with add instruction using !dbg identifier.

-
-
+    
       %indvar.next = add i64 %indvar, 1, !dbg !21
     
-

@@ -3550,7 +3500,7 @@ Instruction

If the exact keyword is present, the result value of the sdiv is a trap value if the result would - be rounded or if overflow would occur.

+ be rounded.

Example:
@@ -4377,8 +4327,8 @@ Instruction 
 
 
Syntax:
-  store <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal !]                   ; yields {void}
-  volatile store <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal !]          ; yields {void}
+  store <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>]                   ; yields {void}
+  volatile store <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>]          ; yields {void}
 
Overview:
@@ -4403,7 +4353,7 @@ Instruction produce less efficient code. An alignment of 1 is always safe.

The optional !nontemporal metadata must reference a single metatadata - name corresponding to a metadata node with one i32 entry of + name <index> corresponding to a metadata node with one i32 entry of value 1. The existence of the !nontemporal metatadata on the instruction tells the optimizer and code generator that this load is not expected to be reused in the cache. The code generator may @@ -4470,8 +4420,7 @@ Instruction

For example, let's consider a C code fragment and how it gets compiled to LLVM:

-
-
+
 struct RT {
   char A;
   int B[10][20];
@@ -4487,12 +4436,10 @@ int *foo(struct ST *s) {
   return &s[1].Z.B[5][13];
 }
 
-

The LLVM code generated by the GCC frontend is:

-
-
+
 %RT = type { i8 , [10 x [20 x i32]], i8  }
 %ST = type { i32, double, %RT }
 
@@ -4502,7 +4449,6 @@ entry:
   ret i32* %reg
 }
 
-
Semantics:

In the example above, the first index is indexing into the '%ST*' @@ -5573,8 +5519,7 @@ freestanding environments and non-C-based languages.

instruction and the variable argument handling intrinsic functions are used.

-
-
+
 define i32 @test(i32 %X, ...) {
   ; Initialize variable argument processing
   %ap = alloca i8*
@@ -5599,7 +5544,6 @@ declare void @llvm.va_start(i8*)
 declare void @llvm.va_copy(i8*, i8*)
 declare void @llvm.va_end(i8*)
 
-
@@ -6965,14 +6909,12 @@ LLVM.

pointer has signature i32 (i32, i32)*. It can be created as follows:

-
-
+
   %tramp = alloca [10 x i8], align 4 ; size and alignment only correct for X86
   %tramp1 = getelementptr [10 x i8]* %tramp, i32 0, i32 0
   %p = call i8* @llvm.init.trampoline(i8* %tramp1, i8* bitcast (i32 (i8* nest , i32, i32)* @f to i8*), i8* %nval)
   %fp = bitcast i8* %p to i32 (i32, i32)*
 
-

The call %val = call i32 %fp(i32 %x, i32 %y) is then equivalent to %val = call i32 %f(i8* %nval, i32 %x, i32 %y).