X-Git-Url: http://plrg.eecs.uci.edu/git/?a=blobdiff_plain;f=docs%2FLangRef.rst;h=d2f9a1d4f16bdf136436373e9b1a6e2e2641ab9e;hb=1ce308866915c9eab78486066d28d2107b7fede2;hp=adf3266b02962109b274d0e0913a224983d38fb2;hpb=2ce21220d8318494f1d3da8d0bcdefca670a2fcd;p=oota-llvm.git diff --git a/docs/LangRef.rst b/docs/LangRef.rst index adf3266b029..d2f9a1d4f16 100644 --- a/docs/LangRef.rst +++ b/docs/LangRef.rst @@ -440,6 +440,9 @@ styles: defining module will bind to the local symbol. That is, the symbol cannot be overridden by another module. +A symbol with ``internal`` or ``private`` linkage must have ``default`` +visibility. + .. _namedtypes: DLL Storage Classes @@ -681,6 +684,10 @@ the aliasee. The aliasee must be a definition. +Aliases are not allowed to point to aliases with linkages that can be +overridden. Since they are only a second name, the possibility of the +intermediate alias being overridden cannot be represented in an object file. + .. _namedmetadatastructure: Named Metadata @@ -798,6 +805,9 @@ Currently, only the following parameter attributes are defined: not to trap and to be properly aligned. This may only be applied to the first parameter. This is not a valid attribute for return values. + +.. _noalias: + ``noalias`` This indicates that pointer values :ref:`based ` on the argument or return value do not alias pointer values which are @@ -807,8 +817,8 @@ Currently, only the following parameter attributes are defined: "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 `_. + details, please see the discussion of the NoAlias response in :ref:`alias + analysis `. Note that this definition of ``noalias`` is intentionally similar to the definition of ``restrict`` in C99 for function arguments, @@ -1982,6 +1992,8 @@ notion of a forward declared structure. | ``opaque`` | An opaque type. | +--------------+-------------------+ +.. _constants: + Constants ========= @@ -3140,14 +3152,18 @@ The '``llvm.global_ctors``' Global Variable .. code-block:: llvm - %0 = type { i32, void ()* } - @llvm.global_ctors = appending global [1 x %0] [%0 { i32 65535, void ()* @ctor }] + %0 = type { i32, void ()*, i8* } + @llvm.global_ctors = appending global [1 x %0] [%0 { i32 65535, void ()* @ctor, i8* @data }] The ``@llvm.global_ctors`` array contains a list of constructor -functions and associated priorities. The functions referenced by this -array will be called in ascending order of priority (i.e. lowest first) -when the module is loaded. The order of functions with the same priority -is not defined. +functions, priorities, and an optional associated global or function. +The functions referenced by this array will be called in ascending order +of priority (i.e. lowest first) when the module is loaded. The order of +functions with the same priority is not defined. + +If the third field is present, non-null, and points to a global variable +or function, the initializer function will only run if the associated +data from the current module is not discarded. .. _llvmglobaldtors: @@ -3156,14 +3172,18 @@ The '``llvm.global_dtors``' Global Variable .. code-block:: llvm - %0 = type { i32, void ()* } - @llvm.global_dtors = appending global [1 x %0] [%0 { i32 65535, void ()* @dtor }] + %0 = type { i32, void ()*, i8* } + @llvm.global_dtors = appending global [1 x %0] [%0 { i32 65535, void ()* @dtor, i8* @data }] + +The ``@llvm.global_dtors`` array contains a list of destructor +functions, priorities, and an optional associated global or function. +The functions referenced by this array will be called in descending +order of priority (i.e. highest first) when the module is loaded. The +order of functions with the same priority is not defined. -The ``@llvm.global_dtors`` array contains a list of destructor functions -and associated priorities. The functions referenced by this array will -be called in descending order of priority (i.e. highest first) when the -module is loaded. The order of functions with the same priority is not -defined. +If the third field is present, non-null, and points to a global variable +or function, the destructor function will only run if the associated +data from the current module is not discarded. Instruction Reference ===================== @@ -4461,7 +4481,7 @@ Syntax: :: - = extractelement > , i32 ; yields + = extractelement > , ; yields Overview: """"""""" @@ -4475,7 +4495,7 @@ Arguments: The first operand of an '``extractelement``' instruction is a value of :ref:`vector ` type. The second operand is an index indicating the position from which to extract the element. The index may be a -variable. +variable of any integer type. Semantics: """""""""" @@ -4501,7 +4521,7 @@ Syntax: :: - = insertelement > , , i32 ; yields > + = insertelement > , , ; yields > Overview: """"""""" @@ -4516,7 +4536,7 @@ The first operand of an '``insertelement``' instruction is a value of :ref:`vector ` type. The second operand is a scalar value whose type must equal the element type of the first operand. The third operand is an index indicating the position at which to insert the value. The -index may be a variable. +index may be a variable of any integer type. Semantics: """""""""" @@ -6152,7 +6172,7 @@ Syntax: :: - = [tail] call [cconv] [ret attrs] [*] () [fn attrs] + = [tail | musttail] call [cconv] [ret attrs] [*] () [fn attrs] Overview: """"""""" @@ -6164,17 +6184,34 @@ Arguments: This instruction requires several arguments: -#. The optional "tail" marker indicates that the callee function does - not access any allocas or varargs in the caller. Note that calls may - be marked "tail" even if they do not occur before a - :ref:`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 `_. - 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: +#. The optional ``tail`` and ``musttail`` markers indicate that the optimizers + should perform tail call optimization. The ``tail`` marker is a hint that + `can be ignored `_. The ``musttail`` marker + means that the call must be tail call optimized in order for the program to + be correct. The ``musttail`` marker provides these guarantees: + + #. The call will not cause unbounded stack growth if it is part of a + recursive cycle in the call graph. + #. Arguments with the :ref:`inalloca ` attribute are + forwarded in place. + + Both markers imply that the callee does not access allocas or varargs from + the caller. Calls marked ``musttail`` must obey the following additional + rules: + + - The call must immediately precede a :ref:`ret ` instruction, + or a pointer bitcast followed by a ret instruction. + - The ret instruction must return the (possibly bitcasted) value + produced by the call or void. + - The caller and callee prototypes must match. Pointer types of + parameters or return types may differ in pointee type, but not + in address space. + - The calling conventions of the caller and callee must match. + - All ABI-impacting function attributes, such as sret, byval, inreg, + returned, and inalloca, must match. + + Tail call optimization for calls marked ``tail`` is guaranteed to occur if + the following conditions are met: - Caller and callee both have the calling convention ``fastcc``. - The call is in tail position (ret immediately follows call and ret @@ -6778,6 +6815,51 @@ Note that calling this intrinsic does not prevent function inlining or other aggressive transformations, so the value returned may not be that of the obvious source-language caller. +.. _int_read_register: +.. _int_write_register: + +'``llvm.read_register``' and '``llvm.write_register``' Intrinsics +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" + +:: + + declare i32 @llvm.read_register.i32(metadata) + declare i64 @llvm.read_register.i64(metadata) + declare void @llvm.write_register.i32(metadata, i32 @value) + declare void @llvm.write_register.i64(metadata, i64 @value) + !0 = metadata !{metadata !"sp\00"} + +Overview: +""""""""" + +The '``llvm.read_register``' and '``llvm.write_register``' intrinsics +provides access to the named register. The register must be valid on +the architecture being compiled to. The type needs to be compatible +with the register being read. + +Semantics: +"""""""""" + +The '``llvm.read_register``' intrinsic returns the current value of the +register, where possible. The '``llvm.write_register``' intrinsic sets +the current value of the register, where possible. + +This is useful to implement named register global variables that need +to always be mapped to a specific register, as is common practice on +bare-metal programs including OS kernels. + +The compiler doesn't check for register availability or use of the used +register in surrounding code, including inline assembly. Because of that, +allocatable registers are not supported. + +Warning: So far it only works with the stack pointer on selected +architectures (ARM, ARM64, AArch64, PowerPC and x86_64). Significant amount of +work is needed to support other registers and even more so, allocatable +registers. + .. _int_stacksave: '``llvm.stacksave``' Intrinsic @@ -6960,11 +7042,11 @@ Semantics: On platforms with coherent instruction and data caches (e.g. x86), this intrinsic is a nop. On platforms with non-coherent instruction and data -cache (e.g. ARM, MIPS), the intrinsic is lowered either to appropiate +cache (e.g. ARM, MIPS), the intrinsic is lowered either to appropriate instructions or a system call, if cache flushing requires special privileges. -The default behavior is to emit a call to ``__clear_cache'' from the run +The default behavior is to emit a call to ``__clear_cache`` from the run time library. This instrinsic does *not* empty the instruction pipeline. Modifications