From fc6b895b5b0c9424f462c8729de519809f8b00e0 Mon Sep 17 00:00:00 2001 From: John Criswell Date: Mon, 16 May 2005 16:17:45 +0000 Subject: [PATCH] Added a note about how the type can be omitted in call instructions. Added a note about how getelementptr can be used to index into structures or arrays. Fixed some typos, spelling, etc. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@22083 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/LangRef.html | 38 +++++++++++++++++++++----------------- 1 file changed, 21 insertions(+), 17 deletions(-) diff --git a/docs/LangRef.html b/docs/LangRef.html index 24587349fd2..d5abdce7af0 100644 --- a/docs/LangRef.html +++ b/docs/LangRef.html @@ -1918,7 +1918,8 @@ subelement of an aggregate data structure.

elements of the aggregate object to index to. The actual types of the arguments provided depend on the type of the first pointer argument. The 'getelementptr' instruction is used to index down through the type -levels of a structure. When indexing into a structure, only uint +levels of a structure or to a specific index in an array. When indexing into a +structure, only uint integer constants are allowed. When indexing into an array or pointer, int and long indexes are allowed of any sign.

@@ -1972,7 +1973,7 @@ the structure, yielding a '%RT' = '{ sbyte, [10 x [20 x int]], sbyte }' type, another structure. The third index indexes into the second element of the structure, yielding a '[10 x [20 x int]]' type, an array. The two dimensions of the array are subscripted into, yielding an -'int' type. The 'getelementptr' instruction return a pointer +'int' type. The 'getelementptr' instruction returns a pointer to this element, thus computing a value of 'int*' type.

Note that it is perfectly legal to index partially through a @@ -2119,7 +2120,7 @@ The 'select' instruction requires a boolean value indicating the condit

If the boolean condition evaluates to true, the instruction returns the first -value argument, otherwise it returns the second value argument. +value argument; otherwise, it returns the second value argument.

Example:
@@ -2169,13 +2170,14 @@ value argument, otherwise it returns the second value argument.

  • 'ty': shall be the signature of the pointer to function value being invoked. The argument types must match the types implied by this - signature.

    + signature. This type can be omitted if the function is not varargs and + if the function type does not return a pointer to a function.

  • 'fnptrval': An LLVM value containing a pointer to a function to be invoked. In most cases, this is a direct function invocation, but indirect calls are just as possible, calling an arbitrary pointer - to function values.

    + to function value.

  • 'function args': argument list whose types match the @@ -2248,9 +2250,9 @@ function.

    vanext is an LLVM instruction instead of an intrinsic function because it takes a type as an -argument. The type refers to the current argument in the va_list, it +argument. The type refers to the current argument in the va_list; it tells the compiler how far on the stack it needs to advance to find the next -argument

    +argument.

    Example:
    @@ -2297,7 +2299,7 @@ take a variable number of arguments, for example, the vfprintf function.

    vaarg is an LLVM instruction instead of an intrinsic function because it takes an type as an +href="#intrinsics">intrinsic function because it takes a type as an argument.

    Example:
    @@ -2313,14 +2315,14 @@ argument.

    LLVM supports the notion of an "intrinsic function". These functions have -well known names and semantics, and are required to follow certain +well known names and semantics and are required to follow certain restrictions. Overall, these instructions represent an extension mechanism for the LLVM language that does not require changing all of the transformations in LLVM to add to the language (or the bytecode reader/writer, the parser, etc...).

    -

    Intrinsic function names must all start with an "llvm." prefix, this -prefix is reserved in LLVM for intrinsic names, thus functions may not be named +

    Intrinsic function names must all start with an "llvm." prefix. This +prefix is reserved in LLVM for intrinsic names; thus, functions may not be named this. Intrinsic functions must always be external functions: you cannot define the body of intrinsic functions. Intrinsic functions may only be used in call or invoke instructions: it is illegal to take the address of an intrinsic @@ -2328,7 +2330,7 @@ function. Additionally, because intrinsic functions are part of the LLVM language, it is required that they all be documented here if any are added.

    -

    To learn how to add an intrinsics, please see the To learn how to add an intrinsic function, please see the Extending LLVM Guide.

    @@ -2396,7 +2398,7 @@ macro available in C. In a target-dependent way, it initializes and returns a va_list element, so that the next vaarg will produce the first variable argument passed to the function. Unlike the C va_start macro, this intrinsic does not need to know the -last argument of the function, the compiler can figure that out.

    +last argument of the function; the compiler can figure that out.

    Note that this intrinsic function is only legal to be called from within the body of a variable argument function.

    @@ -2693,8 +2695,9 @@ source-language caller.

    The 'llvm.prefetch' intrinsic is a hint to the code generator to insert -a prefetch instruction if supported, otherwise it is a noop. Prefetches have no -effect on the behavior of the program, but can change its performance +a prefetch instruction if supported; otherwise, it is a noop. Prefetches have +no +effect on the behavior of the program but can change its performance characteristics.

    @@ -2735,13 +2738,14 @@ performance.

    -The 'llvm.pcmarker' intrinsic is a method to export a PC in a region of +The 'llvm.pcmarker' intrinsic is a method to export a Program Counter +(PC) in a region of code to simulators and other tools. The method is target specific, but it is expected that the marker will use exported symbols to transmit the PC of the marker. The marker makes no guaranties that it will remain with any specific instruction after optimizations. It is possible that the presense of a marker will inhibit optimizations. The intended use is to be inserted after optmizations to allow -corrolations of simulation runs. +correlations of simulation runs.

    Arguments:
    -- 2.34.1