X-Git-Url: http://plrg.eecs.uci.edu/git/?a=blobdiff_plain;f=docs%2FLangRef.html;h=1b94ab5a9a705faa034ac9f76a3faac702937e03;hb=83821c8941b7e9e70de9d5e76556b07872ac371b;hp=7cfa05205cead0d9264a0acfdabdf00c95d263c7;hpb=e1d50cd5e4ff7f4d977cc8bda720a58737e7cf8d;p=oota-llvm.git diff --git a/docs/LangRef.html b/docs/LangRef.html index 7cfa05205ce..1b94ab5a9a7 100644 --- a/docs/LangRef.html +++ b/docs/LangRef.html @@ -255,6 +255,12 @@
The call instructions that wrap inline asm nodes may have a "!srcloc" MDNode + attached to it that contains a constant integer. If present, the code + generator will use the integer as the location cookie value when report + errors through the LLVMContext error reporting mechanisms. This allows a + front-end to corrolate 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.
There are six different terminator instructions: the +
There are seven different terminator instructions: the 'ret' instruction, the 'br' instruction, the 'switch' instruction, the @@ -5149,8 +5200,11 @@ Loop: ; Infinite loop that counts from 0 on up... a ret instruction. If the "tail" marker is present, the function call is eligible for tail call optimization, but might not in fact be - optimized into a jump. As of this writing, the extra requirements for - a call to actually be optimized are: + optimized into a jump. The code generator may optimize calls marked + "tail" with either 1) automatic + sibling call optimization when the caller and callee have + matching signatures, or 2) forced tail call optimization when the + following extra requirements are met:
This is an overloaded intrinsic. You can use llvm.memcpy on any - integer bit width. Not all targets support all bit widths however.
+ integer bit width and for different address spaces. Not all targets support + all bit widths however.- declare void @llvm.memcpy.i8(i8 * <dest>, i8 * <src>, - i8 <len>, i32 <align>) - declare void @llvm.memcpy.i16(i8 * <dest>, i8 * <src>, - i16 <len>, i32 <align>) - declare void @llvm.memcpy.i32(i8 * <dest>, i8 * <src>, - i32 <len>, i32 <align>) - declare void @llvm.memcpy.i64(i8 * <dest>, i8 * <src>, - i64 <len>, i32 <align>) + declare void @llvm.memcpy.p0i8.p0i8.i32(i8 * <dest>, i8 * <src>, + i32 <len>, i32 <align>, i1 <isvolatile>) + declare void @llvm.memcpy.p0i8.p0i8.i64(i8 * <dest>, i8 * <src>, + i64 <len>, i32 <align>, i1 <isvolatile>)
Note that, unlike the standard libc function, the llvm.memcpy.* - intrinsics do not return a value, and takes an extra alignment argument.
+ intrinsics do not return a value, takes extra alignment/isvolatile arguments + and the pointers can be in specified address spaces.The first argument is a pointer to the destination, the second is a pointer to the source. The third argument is an integer argument specifying the - number of bytes to copy, and the fourth argument is the alignment of the - source and destination locations.
+ number of bytes to copy, the fourth argument is the alignment of the + source and destination locations, and the fifth is a boolean indicating a + volatile access.If the call to this intrinsic has an alignment value that is not 0 or 1, then the caller guarantees that both the source and destination pointers are aligned to that boundary.
+Volatile accesses should not be deleted if dead, but the access behavior is + not very cleanly specified and it is unwise to depend on it.
+The 'llvm.memcpy.*' intrinsics copy a block of memory from the source location to the destination location, which are not allowed to overlap. It copies "len" bytes of memory over. If the argument is known to @@ -5884,17 +5942,14 @@ LLVM.
This is an overloaded intrinsic. You can use llvm.memmove on any integer bit - width. Not all targets support all bit widths however.
+ width and for different address space. Not all targets support all bit + widths however.- declare void @llvm.memmove.i8(i8 * <dest>, i8 * <src>, - i8 <len>, i32 <align>) - declare void @llvm.memmove.i16(i8 * <dest>, i8 * <src>, - i16 <len>, i32 <align>) - declare void @llvm.memmove.i32(i8 * <dest>, i8 * <src>, - i32 <len>, i32 <align>) - declare void @llvm.memmove.i64(i8 * <dest>, i8 * <src>, - i64 <len>, i32 <align>) + declare void @llvm.memmove.p0i8.p0i8.i32(i8 * <dest>, i8 * <src>, + i32 <len>, i32 <align>, i1 <isvolatile>) + declare void @llvm.memmove.p0i8.p0i8.i64(i8 * <dest>, i8 * <src>, + i64 <len>, i32 <align>, i1 <isvolatile>)
Note that, unlike the standard libc function, the llvm.memmove.* - intrinsics do not return a value, and takes an extra alignment argument.
+ intrinsics do not return a value, takes extra alignment/isvolatile arguments + and the pointers can be in specified address spaces.The first argument is a pointer to the destination, the second is a pointer to the source. The third argument is an integer argument specifying the - number of bytes to copy, and the fourth argument is the alignment of the - source and destination locations.
+ number of bytes to copy, the fourth argument is the alignment of the + source and destination locations, and the fifth is a boolean indicating a + volatile access.If the call to this intrinsic has an alignment value that is not 0 or 1, then the caller guarantees that the source and destination pointers are aligned to that boundary.
+Volatile accesses should not be deleted if dead, but the access behavior is + not very cleanly specified and it is unwise to depend on it.
+The 'llvm.memmove.*' intrinsics copy a block of memory from the source location to the destination location, which may overlap. It copies "len" bytes of memory over. If the argument is known to be aligned to some @@ -5934,17 +5996,14 @@ LLVM.
This is an overloaded intrinsic. You can use llvm.memset on any integer bit - width. Not all targets support all bit widths however.
+ width and for different address spaces. Not all targets support all bit + widths however.- declare void @llvm.memset.i8(i8 * <dest>, i8 <val>, - i8 <len>, i32 <align>) - declare void @llvm.memset.i16(i8 * <dest>, i8 <val>, - i16 <len>, i32 <align>) - declare void @llvm.memset.i32(i8 * <dest>, i8 <val>, - i32 <len>, i32 <align>) - declare void @llvm.memset.i64(i8 * <dest>, i8 <val>, - i64 <len>, i32 <align>) + declare void @llvm.memset.p0i8.i32(i8 * <dest>, i8 <val>, + i32 <len>, i32 <align>, i1 <isvolatile>) + declare void @llvm.memset.p0i8.i64(i8 * <dest>, i8 <val>, + i64 <len>, i32 <align>, i1 <isvolatile>)
Note that, unlike the standard libc function, the llvm.memset - intrinsic does not return a value, and takes an extra alignment argument.
+ intrinsic does not return a value, takes extra alignment/volatile arguments, + and the destination can be in an arbitrary address space.The first argument is a pointer to the destination to fill, the second is the @@ -5964,6 +6024,9 @@ LLVM.
then the caller guarantees that the destination pointer is aligned to that boundary. +Volatile accesses should not be deleted if dead, but the access behavior is + not very cleanly specified and it is unwise to depend on it.
+The 'llvm.memset.*' intrinsics fill "len" bytes of memory starting at the destination location. If the argument is known to be aligned to some @@ -6583,6 +6646,97 @@ LLVM.
+ + + +Half precision floating point is a storage-only format. This means that it is + a dense encoding (in memory) but does not support computation in the + format.
+ +This means that code must first load the half-precision floating point + value as an i16, then convert it to float with llvm.convert.from.fp16. + Computation can then be performed on the float value (including extending to + double etc). To store the value back to memory, it is first converted to + float if needed, then converted to i16 with + llvm.convert.to.fp16, then + storing as an i16 value.
++ declare i16 @llvm.convert.to.fp16(f32 %a) ++ +
The 'llvm.convert.to.fp16' intrinsic function performs + a conversion from single precision floating point format to half precision + floating point format.
+ +The intrinsic function contains single argument - the value to be + converted.
+ +The 'llvm.convert.to.fp16' intrinsic function performs + a conversion from single precision floating point format to half precision + floating point format. The return value is an i16 which + contains the converted number.
+ ++ %res = call i16 @llvm.convert.to.fp16(f32 %a) + store i16 %res, i16* @x, align 2 ++ +
+ declare f32 @llvm.convert.from.fp16(i16 %a) ++ +
The 'llvm.convert.from.fp16' intrinsic function performs + a conversion from half precision floating point format to single precision + floating point format.
+ +The intrinsic function contains single argument - the value to be + converted.
+ +The 'llvm.convert.from.fp16' intrinsic function performs a + conversion from half single precision floating point format to single + precision floating point format. The input half-float value is represented by + an i16 value.
+ ++ %a = load i16* @x, align 2 + %res = call f32 @llvm.convert.from.fp16(i16 %a) ++ +