LLVM programs are composed of "Module"s, each of which is a translation unit - of the input programs. Each module consists of functions, global variables, - and symbol table entries. Modules may be combined together with the LLVM - linker, which merges function (and global variable) definitions, resolves - forward declarations, and merges symbol table entries. Here is an example of - the "hello world" module:
+LLVM programs are composed of Modules, each of which is a + translation unit of the input programs. Each module consists of functions, + global variables, and symbol table entries. Modules may be combined together + with the LLVM linker, which merges function (and global variable) + definitions, resolves 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]* +@.str = private unnamed_addr constant [13 x i8] c"hello world\0A\00" ; External declaration of the puts function -declare i32 @puts(i8*) ; i32 (i8*)* +declare i32 @puts(i8* nocapture) nounwind ; 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* + %cast210 = getelementptr [13 x i8]* @.str, i64 0, i64 0 ; Call puts function to write out the string to stdout. - call i32 @puts(i8* %cast210) ; i32 + call i32 @puts(i8* %cast210) ret i32 0 } ; Named metadata -!1 = metadata !{i32 41} +!1 = metadata !{i32 42} !foo = !{!1, null}
This example is made up of a global variable named - ".LC0", an external declaration of the "puts" function, + ".str", an external declaration of the "puts" function, a function definition for "main" and named metadata - "foo".
+ "foo". -In general, a module is made up of a list of global values, where both - functions and global variables are global values. Global values are +
In general, a module is made up of a list of global values (where both + functions and global variables are global values). Global values are represented by a pointer to a memory location (in this case, a pointer to an array of char, and a pointer to a function), and have one of the following linkage types.
@@ -2994,14 +3002,16 @@ call void @llvm.dbg.value(metadata !24, i64 0, metadata !25)fpaccuracy metadata may be attached to any instruction of floating - point type. It expresses the maximum relative error of the result of - that instruction, in ULPs. ULP is defined as follows:
+fpmath metadata may be attached to any instruction of floating point + type. It can be used to express the maximum acceptable error in the result of + that instruction, in ULPs, thus potentially allowing the compiler to use a + more efficient but less accurate method of computing it. ULP is defined as + follows:
@@ -3013,18 +3023,253 @@ call void @llvm.dbg.value(metadata !24, i64 0, metadata !25)-
The maximum relative error may be any rational number. The metadata node - shall consist of a pair of unsigned integers respectively representing - the numerator and denominator. For example, 2.5 ULP:
+The metadata node shall consist of a single positive floating point number + representing the maximum relative error, for example:
-!0 = metadata !{ i32 5, i32 2 }
+!0 = metadata !{ float 2.5 } ; maximum acceptable inaccuracy is 2.5 ULPs
range metadata may be attached only to loads of integer types. It + expresses the possible ranges the loaded value is in. The ranges are + represented with a flattened list of integers. The loaded value is known to + be in the union of the ranges defined by each consecutive pair. Each pair + has the following properties:
+Examples:
+
+ %a = load i8* %x, align 1, !range !0 ; Can only be 0 or 1
+ %b = load i8* %y, align 1, !range !1 ; Can only be 255 (-1), 0 or 1
+ %c = load i8* %z, align 1, !range !2 ; Can only be 0, 1, 3, 4 or 5
+...
+!0 = metadata !{ i8 0, i8 2 }
+!1 = metadata !{ i8 255, i8 2 }
+!2 = metadata !{ i8 0, i8 2, i8 3, i8 6 }
+
+Information about the module as a whole is difficult to convey to LLVM's + subsystems. The LLVM IR isn't sufficient to transmit this + information. The llvm.module.flags named metadata exists in order to + facilitate this. These flags are in the form of key / value pairs — + much like a dictionary — making it easy for any subsystem who cares + about a flag to look it up.
+ +The llvm.module.flags metadata contains a list of metadata + triplets. Each triplet has the following form:
+ +When two (or more) modules are merged together, the resulting + llvm.module.flags metadata is the union of the + modules' llvm.module.flags metadata. The only exception being a flag + with the Override behavior, which may override another flag's value + (see below).
+ +The following behaviors are supported:
+ +| Value | +Behavior | +
|---|---|
| 1 | +
+
|
+
| 2 | +
+
|
+
| 3 | +
+
|
+
| 4 | +
+
|
+
An example of module flags:
+ +
+!0 = metadata !{ i32 1, metadata !"foo", i32 1 }
+!1 = metadata !{ i32 4, metadata !"bar", i32 37 }
+!2 = metadata !{ i32 2, metadata !"qux", i32 42 }
+!3 = metadata !{ i32 3, metadata !"qux",
+ metadata !{
+ metadata !"foo", i32 1
+ }
+}
+!llvm.module.flags = !{ !0, !1, !2, !3 }
+
+
+Metadata !0 has the ID !"foo" and the value '1'. The + behavior if two or more !"foo" flags are seen is to emit an + error if their values are not equal.
Metadata !1 has the ID !"bar" and the value '37'. The + behavior if two or more !"bar" flags are seen is to use the + value '37' if their values are not equal.
Metadata !2 has the ID !"qux" and the value '42'. The + behavior if two or more !"qux" flags are seen is to emit a + warning if their values are not equal.
Metadata !3 has the ID !"qux" and the value:
+ +
+metadata !{ metadata !"foo", i32 1 }
+
+
+ The behavior is to emit an error if the llvm.module.flags does + not contain a flag with the ID !"foo" that has the value + '1'. If two or more !"qux" flags exist, then they must have + the same value or an error will be issued.
On the Mach-O platform, Objective-C stores metadata about garbage collection + in a special section called "image info". The metadata consists of a version + number and a bitmask specifying what types of garbage collection are + supported (if any) by the file. If two or more modules are linked together + their garbage collection metadata needs to be merged rather than appended + together.
+ +The Objective-C garbage collection module flags metadata consists of the + following key-value pairs:
+ +| Key | +Value | +
|---|---|
| Objective-C Version | +[Required] — The Objective-C ABI + version. Valid values are 1 and 2. | +
| Objective-C Image Info Version | +[Required] — The version of the image info + section. Currently always 0. | +
| Objective-C Image Info Section | +[Required] — The section to place the + metadata. Valid values are "__OBJC, __image_info, regular" for + Objective-C ABI version 1, and "__DATA,__objc_imageinfo, regular, + no_dead_strip" for Objective-C ABI version 2. | +
| Objective-C Garbage Collection | +[Required] — Specifies whether garbage + collection is supported or not. Valid values are 0, for no garbage + collection, and 2, for garbage collection supported. | +
| Objective-C GC Only | +[Optional] — Specifies that only garbage + collection is supported. If present, its value must be 6. This flag + requires that the Objective-C Garbage Collection flag have the + value 2. | +
Some important flag interactions:
+ +
@@ -8151,6 +8400,30 @@ LLVM. + +
+ declare void @llvm.debugger() ++ +
The 'llvm.debugger' intrinsic.
+ +None.
+ +This intrinsic is lowered to code which is intended to cause an execution + trap with the intention of requesting the attention of a debugger.
+ +- declare i32 @llvm.objectsize.i32(i8* <object>, i1 <type>) - declare i64 @llvm.objectsize.i64(i8* <object>, i1 <type>) + declare i32 @llvm.objectsize.i32(i8* <object>, i1 <min>, i32 <runtime>) + declare i64 @llvm.objectsize.i64(i8* <object>, i1 <min>, i32 <runtime>)
The llvm.objectsize intrinsic takes two arguments. The first +
The llvm.objectsize intrinsic takes three arguments. The first argument is a pointer to or into the object. The second argument - is a boolean 0 or 1. This argument determines whether you want the - maximum (0) or minimum (1) bytes remaining. This needs to be a literal 0 or - 1, variables are not allowed.
+ is a boolean and determines whether llvm.objectsize returns 0 (if true) + or -1 (if false) when the object size is unknown. + The third argument, runtime, indicates whether the compiler is allowed + to return a non-constant value. The higher the value, the higher the potential + run-time performance impact. + The second and third arguments only accepts constants.The llvm.objectsize intrinsic is lowered to either a constant - representing the size of the object concerned, or i32/i64 -1 or 0, - depending on the type argument, if the size cannot be determined at - compile time.
+The llvm.objectsize intrinsic is lowered to a constant representing + the size of the object concerned. If the size cannot be determined at compile + time, llvm.objectsize either returns i32/i64 -1 or 0 + (depending on the min argument) if runtime is 0, or a run-time + value (if runtime > 0 and an expression could be generated).