.. contents::
:local:
- :depth: 3
+ :depth: 4
Abstract
========
#. Unnamed temporaries are created when the result of a computation is
not assigned to a named value.
#. Unnamed temporaries are numbered sequentially (using a per-function
- incrementing counter, starting with 0).
+ incrementing counter, starting with 0). Note that basic blocks are
+ included in this numbering. For example, if the entry basic block is not
+ given a label name, then it will get number 0.
It also shows a convention that we follow in this document. When
demonstrating instructions, we will follow an instruction with a comment
visible, meaning that it participates in linkage and can be used to
resolve external symbol references.
-The next two types of linkage are targeted for Microsoft Windows
-platform only. They are designed to support importing (exporting)
-symbols from (to) DLLs (Dynamic Link Libraries).
-
-``dllimport``
- "``dllimport``" linkage causes the compiler to reference a function
- or variable via a global pointer to a pointer that is set up by the
- DLL exporting the symbol. On Microsoft Windows targets, the pointer
- name is formed by combining ``__imp_`` and the function or variable
- name.
-``dllexport``
- "``dllexport``" linkage causes the compiler to provide a global
- pointer to a pointer in a DLL, so that it can be referenced with the
- ``dllimport`` attribute. On Microsoft Windows targets, the pointer
- name is formed by combining ``__imp_`` and the function or variable
- name.
-
-For example, since the "``.LC0``" variable is defined to be internal, if
-another module defined a "``.LC0``" variable and was linked with this
-one, one of the two would be renamed, preventing a collision. Since
-"``main``" and "``puts``" are external (i.e., lacking any linkage
-declarations), they are accessible outside of the current module.
-
It is illegal for a function *declaration* to have any linkage type
-other than ``external``, ``dllimport`` or ``extern_weak``.
+other than ``external`` or ``extern_weak``.
.. _callingconv:
accessed runtime components pinned to specific hardware registers.
At the moment only X86 supports this convention (both 32 and 64
bit).
+"``webkit_jscc``" - WebKit's JavaScript calling convention
+ This calling convention has been implemented for `WebKit FTL JIT
+ <https://trac.webkit.org/wiki/FTLJIT>`_. It passes arguments on the
+ stack right to left (as cdecl does), and returns a value in the
+ platform's customary return register.
+"``anyregcc``" - Dynamic calling convention for code patching
+ This is a special convention that supports patching an arbitrary code
+ sequence in place of a call site. This convention forces the call
+ arguments into registers but allows them to be dynamcially
+ allocated. This can currently only be used with calls to
+ llvm.experimental.patchpoint because only this intrinsic records
+ the location of its arguments in a side table. See :doc:`StackMaps`.
"``cc <n>``" - Numbered convention
Any calling convention may be specified by number, allowing
target-specific calling conventions to be used. Target specific
.. _namedtypes:
+DLL Storage Classes
+-------------------
+
+All Global Variables, Functions and Aliases can have one of the following
+DLL storage class:
+
+``dllimport``
+ "``dllimport``" causes the compiler to reference a function or variable via
+ a global pointer to a pointer that is set up by the DLL exporting the
+ symbol. On Microsoft Windows targets, the pointer name is formed by
+ combining ``__imp_`` and the function or variable name.
+``dllexport``
+ "``dllexport``" causes the compiler to provide a global pointer to a pointer
+ in a DLL, so that it can be referenced with the ``dllimport`` attribute. On
+ Microsoft Windows targets, the pointer name is formed by combining
+ ``__imp_`` and the function or variable name. Since this storage class
+ exists for defining a dll interface, the compiler, assembler and linker know
+ it is externally referenced and must refrain from deleting the symbol.
+
Named Types
-----------
initial values before the start of the global initializer. This is
true even for variables potentially accessible from outside the
module, including those with external linkage or appearing in
-``@llvm.used``. This assumption may be suppressed by marking the
-variable with ``externally_initialized``.
+``@llvm.used`` or dllexported variables. This assumption may be suppressed
+by marking the variable with ``externally_initialized``.
An explicit alignment may be specified for a global, which must be a
power of 2. If not present, or if the alignment is set to zero, the
iterate over them as an array, alignment padding would break this
iteration.
+Globals can also have a :ref:`DLL storage class <dllstorageclass>`.
+
+Syntax::
+
+ [@<GlobalVarName> =] [Linkage] [Visibility] [DLLStorageClass] [ThreadLocal]
+ [AddrSpace] [unnamed_addr] [ExternallyInitialized]
+ <global | constant> <Type>
+ [, section "name"] [, align <Alignment>]
+
For example, the following defines a global in a numbered address space
with an initializer, section, and alignment:
LLVM function definitions consist of the "``define``" keyword, an
optional :ref:`linkage type <linkage>`, an optional :ref:`visibility
-style <visibility>`, an optional :ref:`calling convention <callingconv>`,
+style <visibility>`, an optional :ref:`DLL storage class <dllstorageclass>`,
+an optional :ref:`calling convention <callingconv>`,
an optional ``unnamed_addr`` attribute, a return type, an optional
:ref:`parameter attribute <paramattrs>` for the return type, a function
name, a (possibly empty) argument list (each with optional :ref:`parameter
LLVM function declarations consist of the "``declare``" keyword, an
optional :ref:`linkage type <linkage>`, an optional :ref:`visibility
-style <visibility>`, an optional :ref:`calling convention <callingconv>`,
+style <visibility>`, an optional :ref:`DLL storage class <dllstorageclass>`,
+an optional :ref:`calling convention <callingconv>`,
an optional ``unnamed_addr`` attribute, a return type, an optional
:ref:`parameter attribute <paramattrs>` for the return type, a function
name, a possibly empty list of arguments, an optional alignment, an optional
Syntax::
- define [linkage] [visibility]
+ define [linkage] [visibility] [DLLStorageClass]
[cconv] [ret attrs]
<ResultType> @<FunctionName> ([argument list])
[fn Attrs] [section "name"] [align N]
Aliases act as "second name" for the aliasee value (which can be either
function, global variable, another alias or bitcast of global value).
-Aliases may have an optional :ref:`linkage type <linkage>`, and an optional
-:ref:`visibility style <visibility>`.
+Aliases may have an optional :ref:`linkage type <linkage>`, an optional
+:ref:`visibility style <visibility>`, and an optional :ref:`DLL storage class
+<dllstorageclass>`.
Syntax::
- @<Name> =
alias [Linkage] [Visibility] <AliaseeTy> @<Aliasee>
+ @<Name> =
[Visibility] [DLLStorageClass] alias [Linkage] <AliaseeTy> @<Aliasee>
The linkage must be one of ``private``, ``linker_private``,
``linker_private_weak``, ``internal``, ``linkonce``, ``weak``,
``linkonce_odr``, ``weak_odr``, ``external``. Note that some system linkers
-might not correctly handle dropping a weak symbol that is aliased by a non weak
+might not correctly handle dropping a weak symbol that is aliased by a non-weak
alias.
.. _namedmetadatastructure:
site. If the alignment is not specified, then the code generator
makes a target-specific assumption.
+.. _attr_inalloca:
+
+``inalloca``
+
+.. Warning:: This feature is unstable and not fully implemented.
+
+ The ``inalloca`` argument attribute allows the caller to get the
+ address of an outgoing argument to a ``call`` or ``invoke`` before
+ it executes. It is similar to ``byval`` in that it is used to pass
+ arguments by value, but it guarantees that the argument will not be
+ copied.
+
+ To be :ref:`well formed <wellformed>`, the caller must pass in an
+ alloca value into an ``inalloca`` parameter, and an alloca may be
+ used as an ``inalloca`` argument at most once. The attribute can
+ only be applied to parameters that would be passed in memory and not
+ registers. The ``inalloca`` attribute cannot be used in conjunction
+ with other attributes that affect argument storage, like ``inreg``,
+ ``nest``, ``sret``, or ``byval``. The ``inalloca`` stack space is
+ considered to be clobbered by any call that uses it, so any
+ ``inalloca`` parameters cannot be marked ``readonly``.
+
+ Allocas passed with ``inalloca`` to a call must be in the opposite
+ order of the parameter list, meaning that the rightmost argument
+ must be allocated first. If a call has inalloca arguments, no other
+ allocas can occur between the first alloca used by the call and the
+ call site, unless they are are cleared by calls to
+ :ref:`llvm.stackrestore <int_stackrestore>`. Violating these rules
+ results in undefined behavior at runtime.
+
+ See :doc:`InAlloca` for more information on how to use this
+ attribute.
+
``sret``
This indicates that the pointer parameter specifies the address of a
structure that is the return value of the function in the source
attribute; this attribute is also incompatible
with the ``minsize`` attribute and the ``optsize`` attribute.
- The inliner should never inline this function in any situation.
+ This attribute requires the ``noinline`` attribute to be specified on
+ the function as well, so the function is never inlined into any caller.
Only functions with the ``alwaysinline`` attribute are valid
- candidates for inlining inside the body of this function.
+ candidates for inlining into the body of this function.
``optsize``
This attribute suggests that optimization passes and code generator
passes make choices that keep the code size of this function low,
``p[n]:<size>:<abi>:<pref>``
This specifies the *size* of a pointer and its ``<abi>`` and
``<pref>``\erred alignments for address space ``n``. All sizes are in
- bits. Specifying the ``<pref>`` alignment is optional. If omitted, the
- preceding ``:`` should be omitted too. The address space, ``n`` is
- optional, and if not specified, denotes the default address space 0.
- The value of ``n`` must be in the range [1,2^23).
+ bits. The address space, ``n`` is optional, and if not specified,
+ denotes the default address space 0. The value of ``n`` must be
+ in the range [1,2^23).
``i<size>:<abi>:<pref>``
This specifies the alignment for an integer type of a given bit
``<size>``. The value of ``<size>`` must be in the range [1,2^23).
will work. 32 (float) and 64 (double) are supported on all targets; 80
or 128 (different flavors of long double) are also supported on some
targets.
-``a<size>:<abi>:<pref>``
- This specifies the alignment for an aggregate type of a given bit
- ``<size>``.
-``s<size>:<abi>:<pref>``
- This specifies the alignment for a stack object of a given bit
- ``<size>``.
+``a:<abi>:<pref>``
+ This specifies the alignment for an object of aggregate type.
+``m:<mangling>``
+ If prerest, specifies that llvm names are mangled in the output. The
+ options are
+ * ``e``: ELF mangling: Private symbols get a ``.L`` prefix.
+ * ``m``: Mips mangling: Private symbols get a ``$`` prefix.
+ * ``o``: Mach-O mangling: Private symbols get ``L`` prefix. Other
+ symbols get a ``_`` prefix.
+ * ``w``: Windows COFF prefix: Similar to Mach-O, but stdcall and fastcall
+ functions also get a suffix based on the frame size.
``n<size1>:<size2>:<size3>...``
This specifies a set of native integer widths for the target CPU in
bits. For example, it might contain ``n32`` for 32-bit PowerPC,
this set are considered to support most general arithmetic operations
efficiently.
+On every specification that takes a ``<abi>:<pref>``, specifying the
+``<pref>`` alignment is optional. If omitted, the preceding ``:``
+should be omitted too and ``<pref>`` will be equal to ``<abi>``.
+
When constructing the data layout for a given target, LLVM starts with a
default set of specifications which are then (possibly) overridden by
the specifications in the ``datalayout`` keyword. The default
- ``f128:128:128`` - quad is 128-bit aligned
- ``v64:64:64`` - 64-bit vector is 64-bit aligned
- ``v128:128:128`` - 128-bit vector is 128-bit aligned
-- ``a0:0:64`` - aggregates are 64-bit aligned
+- ``a:0:64`` - aggregates are 64-bit aligned
When LLVM is determining the alignment for a given type, it uses the
following rules:
generated code and enables novel analyses and transformations that are
not feasible to perform on normal three address code representations.
-.. _typeclassifications:
+.. _t_void:
-Type Classifications
---------------------
+Void Type
+---------
-The types fall into a few useful classifications:
+:Overview:
-.. list-table::
- :header-rows: 1
+The void type does not represent any value and has no size.
+
+:Syntax:
+
+
+::
+
+ void
+
+
+.. _t_function:
+
+Function Type
+-------------
- * - Classification
- - Types
+:Overview:
- * - :ref:`integer <t_integer>`
- - ``i1``, ``i2``, ``i3``, ... ``i8``, ... ``i16``, ... ``i32``, ...
- ``i64``, ...
- * - :ref:`floating point <t_floating>`
- - ``half``, ``float``, ``double``, ``x86_fp80``, ``fp128``,
- ``ppc_fp128``
+The function type can be thought of as a function signature. It consists of a
+return type and a list of formal parameter types. The return type of a function
+type is a void type or first class type --- except for :ref:`label <t_label>`
+and :ref:`metadata <t_metadata>` types.
+
+:Syntax:
+
+::
+ <returntype> (<parameter list>)
- * - first class
+...where '``<parameter list>``' is a comma-separated list of type
+specifiers. Optionally, the parameter list may include a type ``...``, which
+indicates that the function takes a variable number of arguments. Variable
+argument functions can access their arguments with the :ref:`variable argument
+handling intrinsic <int_varargs>` functions. '``<returntype>``' is any type
+except :ref:`label <t_label>` and :ref:`metadata <t_metadata>`.
- .. _t_firstclass:
+:Examples:
- - :ref:`integer <t_integer>`, :ref:`floating point <t_floating>`,
- :ref:`pointer <t_pointer>`, :ref:`vector <t_vector>`,
- :ref:`structure <t_struct>`, :ref:`array <t_array>`,
- :ref:`label <t_label>`, :ref:`metadata <t_metadata>`.
++---------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| ``i32 (i32)`` | function taking an ``i32``, returning an ``i32`` |
++---------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| ``float (i16, i32 *) *`` | :ref:`Pointer <t_pointer>` to a function that takes an ``i16`` and a :ref:`pointer <t_pointer>` to ``i32``, returning ``float``. |
++---------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| ``i32 (i8*, ...)`` | A vararg function that takes at least one :ref:`pointer <t_pointer>` to ``i8`` (char in C), which returns an integer. This is the signature for ``printf`` in LLVM. |
++---------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| ``{i32, i32} (i32)`` | A function taking an ``i32``, returning a :ref:`structure <t_struct>` containing two ``i32`` values |
++---------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+
- * - :ref:`primitive <t_primitive>`
- - :ref:`label <t_label>`,
- :ref:`void <t_void>`,
- :ref:`integer <t_integer>`,
- :ref:`floating point <t_floating>`,
- :ref:`x86mmx <t_x86mmx>`,
- :ref:`metadata <t_metadata>`.
+.. _t_firstclass:
- * - :ref:`derived <t_derived>`
- - :ref:`array <t_array>`,
- :ref:`function <t_function>`,
- :ref:`pointer <t_pointer>`,
- :ref:`structure <t_struct>`,
- :ref:`vector <t_vector>`,
- :ref:`opaque <t_opaque>`.
+First Class Types
+-----------------
The :ref:`first class <t_firstclass>` types are perhaps the most important.
Values of these types are the only ones which can be produced by
instructions.
-.. _t_primitive:
+.. _t_single_value:
-Primitive Types
----------------
+Single Value Types
+^^^^^^^^^^^^^^^^^^
-The primitive types are the fundamental building blocks of the LLVM
-system.
+These are the types that are valid in registers from CodeGen's perspective.
.. _t_integer:
Integer Type
-^^^^^^^^^^^^
+""""""""""""
-Overview:
-"""""""""
+:Overview:
The integer type is a very simple type that simply specifies an
arbitrary bit width for the integer type desired. Any bit width from 1
bit to 2\ :sup:`23`\ -1 (about 8 million) can be specified.
-Syntax:
-"""""""
+:Syntax:
::
value.
Examples:
-"""""""""
+*********
+----------------+------------------------------------------------+
| ``i1`` | a single-bit integer. |
.. _t_floating:
Floating Point Types
-^^^^^^^^^^^^^^^^^^^^
+""""""""""""""""""""
.. list-table::
:header-rows: 1
.. _t_x86mmx:
X86mmx Type
-^^^^^^^^^^^
+"""""""""""
-Overview:
-"""""""""
+:Overview:
The x86mmx type represents a value held in an MMX register on an x86
machine. The operations allowed on it are quite limited: parameters and
and/or results of this type. There are no arrays, vectors or constants
of this type.
-Syntax:
-"""""""
+:Syntax:
::
x86mmx
-.. _t_void:
-Void Type
-^^^^^^^^^
+.. _t_pointer:
-Overview:
-"""""""""
+Pointer Type
+""""""""""""
-The void type does not represent any value and has no size.
+:Overview:
-Syntax:
-"""""""
+The pointer type is used to specify memory locations. Pointers are
+commonly used to reference objects in memory.
+
+Pointer types may have an optional address space attribute defining the
+numbered address space where the pointed-to object resides. The default
+address space is number zero. The semantics of non-zero address spaces
+are target-specific.
+
+Note that LLVM does not permit pointers to void (``void*``) nor does it
+permit pointers to labels (``label*``). Use ``i8*`` instead.
+
+:Syntax:
::
- void
+ <type> *
+
+:Examples:
+
++-------------------------+--------------------------------------------------------------------------------------------------------------+
+| ``[4 x i32]*`` | A :ref:`pointer <t_pointer>` to :ref:`array <t_array>` of four ``i32`` values. |
++-------------------------+--------------------------------------------------------------------------------------------------------------+
+| ``i32 (i32*) *`` | A :ref:`pointer <t_pointer>` to a :ref:`function <t_function>` that takes an ``i32*``, returning an ``i32``. |
++-------------------------+--------------------------------------------------------------------------------------------------------------+
+| ``i32 addrspace(5)*`` | A :ref:`pointer <t_pointer>` to an ``i32`` value that resides in address space #5. |
++-------------------------+--------------------------------------------------------------------------------------------------------------+
+
+.. _t_vector:
+
+Vector Type
+"""""""""""
+
+:Overview:
+
+A vector type is a simple derived type that represents a vector of
+elements. Vector types are used when multiple primitive data are
+operated in parallel using a single instruction (SIMD). A vector type
+requires a size (number of elements) and an underlying primitive data
+type. Vector types are considered :ref:`first class <t_firstclass>`.
+
+:Syntax:
+
+::
+
+ < <# elements> x <elementtype> >
+
+The number of elements is a constant integer value larger than 0;
+elementtype may be any integer or floating point type, or a pointer to
+these types. Vectors of size zero are not allowed.
+
+:Examples:
+
++-------------------+--------------------------------------------------+
+| ``<4 x i32>`` | Vector of 4 32-bit integer values. |
++-------------------+--------------------------------------------------+
+| ``<8 x float>`` | Vector of 8 32-bit floating-point values. |
++-------------------+--------------------------------------------------+
+| ``<2 x i64>`` | Vector of 2 64-bit integer values. |
++-------------------+--------------------------------------------------+
+| ``<4 x i64*>`` | Vector of 4 pointers to 64-bit integer values. |
++-------------------+--------------------------------------------------+
.. _t_label:
Label Type
^^^^^^^^^^
-Overview:
-"""""""""
+:Overview:
The label type represents code labels.
-Syntax:
-"""""""
+:Syntax:
::
Metadata Type
^^^^^^^^^^^^^
-Overview:
-"""""""""
+:Overview:
The metadata type represents embedded metadata. No derived types may be
created from metadata except for :ref:`function <t_function>` arguments.
-Syntax:
-"""""""
+:Syntax:
::
metadata
-.. _t_derived:
-
-Derived Types
--------------
-
-The real power in LLVM comes from the derived types in the system. This
-is what allows a programmer to represent arrays, functions, pointers,
-and other useful types. Each of these types contain one or more element
-types which may be a primitive type, or another derived type. For
-example, it is possible to have a two dimensional array, using an array
-as the element type of another array.
-
.. _t_aggregate:
Aggregate Types
.. _t_array:
Array Type
-^^^^^^^^^^
+""""""""""
-Overview:
-"""""""""
+:Overview:
The array type is a very simple derived type that arranges elements
sequentially in memory. The array type requires a size (number of
elements) and an underlying data type.
-Syntax:
-"""""""
+:Syntax:
::
The number of elements is a constant integer value; ``elementtype`` may
be any type with a size.
-Examples:
-"""""""""
+:Examples:
+------------------+--------------------------------------+
| ``[40 x i32]`` | Array of 40 32-bit integer values. |
arrays' in LLVM could use the type "``{ i32, [0 x float]}``", for
example.
-.. _t_function:
-
-Function Type
-^^^^^^^^^^^^^
-
-Overview:
-"""""""""
-
-The function type can be thought of as a function signature. It consists of a
-return type and a list of formal parameter types. The return type of a function
-type is a void type or first class type --- except for :ref:`label <t_label>`
-and :ref:`metadata <t_metadata>` types.
-
-Syntax:
-"""""""
-
-::
-
- <returntype> (<parameter list>)
-
-...where '``<parameter list>``' is a comma-separated list of type
-specifiers. Optionally, the parameter list may include a type ``...``, which
-indicates that the function takes a variable number of arguments. Variable
-argument functions can access their arguments with the :ref:`variable argument
-handling intrinsic <int_varargs>` functions. '``<returntype>``' is any type
-except :ref:`label <t_label>` and :ref:`metadata <t_metadata>`.
-
-Examples:
-"""""""""
-
-+---------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``i32 (i32)`` | function taking an ``i32``, returning an ``i32`` |
-+---------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``float (i16, i32 *) *`` | :ref:`Pointer <t_pointer>` to a function that takes an ``i16`` and a :ref:`pointer <t_pointer>` to ``i32``, returning ``float``. |
-+---------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``i32 (i8*, ...)`` | A vararg function that takes at least one :ref:`pointer <t_pointer>` to ``i8`` (char in C), which returns an integer. This is the signature for ``printf`` in LLVM. |
-+---------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``{i32, i32} (i32)`` | A function taking an ``i32``, returning a :ref:`structure <t_struct>` containing two ``i32`` values |
-+---------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-
.. _t_struct:
Structure Type
-^^^^^^^^^^^^^^
+""""""""""""""
-Overview:
-"""""""""
+:Overview:
The structure type is used to represent a collection of data members
together in memory. The elements of a structure may be any type that has
or opaque since there is no way to write one. Identified types can be
recursive, can be opaqued, and are never uniqued.
-Syntax:
-"""""""
+:Syntax:
::
%T1 = type { <type list> } ; Identified normal struct type
%T2 = type <{ <type list> }> ; Identified packed struct type
-Examples:
-"""""""""
+:Examples:
+------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| ``{ i32, i32, i32 }`` | A triple of three ``i32`` values |
.. _t_opaque:
Opaque Structure Types
-^^^^^^^^^^^^^^^^^^^^^^
+""""""""""""""""""""""
-Overview:
-"""""""""
+:Overview:
Opaque structure types are used to represent named structure types that
do not have a body specified. This corresponds (for example) to the C
notion of a forward declared structure.
-Syntax:
-"""""""
+:Syntax:
::
%X = type opaque
%52 = type opaque
-Examples:
-"""""""""
+:Examples:
+--------------+-------------------+
| ``opaque`` | An opaque type. |
+--------------+-------------------+
-.. _t_pointer:
-
-Pointer Type
-^^^^^^^^^^^^
-
-Overview:
-"""""""""
-
-The pointer type is used to specify memory locations. Pointers are
-commonly used to reference objects in memory.
-
-Pointer types may have an optional address space attribute defining the
-numbered address space where the pointed-to object resides. The default
-address space is number zero. The semantics of non-zero address spaces
-are target-specific.
-
-Note that LLVM does not permit pointers to void (``void*``) nor does it
-permit pointers to labels (``label*``). Use ``i8*`` instead.
-
-Syntax:
-"""""""
-
-::
-
- <type> *
-
-Examples:
-"""""""""
-
-+-------------------------+--------------------------------------------------------------------------------------------------------------+
-| ``[4 x i32]*`` | A :ref:`pointer <t_pointer>` to :ref:`array <t_array>` of four ``i32`` values. |
-+-------------------------+--------------------------------------------------------------------------------------------------------------+
-| ``i32 (i32*) *`` | A :ref:`pointer <t_pointer>` to a :ref:`function <t_function>` that takes an ``i32*``, returning an ``i32``. |
-+-------------------------+--------------------------------------------------------------------------------------------------------------+
-| ``i32 addrspace(5)*`` | A :ref:`pointer <t_pointer>` to an ``i32`` value that resides in address space #5. |
-+-------------------------+--------------------------------------------------------------------------------------------------------------+
-
-.. _t_vector:
-
-Vector Type
-^^^^^^^^^^^
-
-Overview:
-"""""""""
-
-A vector type is a simple derived type that represents a vector of
-elements. Vector types are used when multiple primitive data are
-operated in parallel using a single instruction (SIMD). A vector type
-requires a size (number of elements) and an underlying primitive data
-type. Vector types are considered :ref:`first class <t_firstclass>`.
-
-Syntax:
-"""""""
-
-::
-
- < <# elements> x <elementtype> >
-
-The number of elements is a constant integer value larger than 0;
-elementtype may be any integer or floating point type, or a pointer to
-these types. Vectors of size zero are not allowed.
-
-Examples:
-"""""""""
-
-+-------------------+--------------------------------------------------+
-| ``<4 x i32>`` | Vector of 4 32-bit integer values. |
-+-------------------+--------------------------------------------------+
-| ``<8 x float>`` | Vector of 8 32-bit floating-point values. |
-+-------------------+--------------------------------------------------+
-| ``<2 x i64>`` | Vector of 2 64-bit integer values. |
-+-------------------+--------------------------------------------------+
-| ``<4 x i64*>`` | Vector of 4 pointers to 64-bit integer values. |
-+-------------------+--------------------------------------------------+
-
Constants
=========
This class of intrinsics exists to information about the lifetime of
memory objects and ranges where variables are immutable.
+.. _int_lifestart:
+
'``llvm.lifetime.start``' Intrinsic
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
to never be used and has an undefined value. A load from the pointer
that precedes this intrinsic can be replaced with ``'undef'``.
+.. _int_lifeend:
+
'``llvm.lifetime.end``' Intrinsic
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This intrinsic does nothing, and it's removed by optimizers and ignored
by codegen.
+
+Stack Map Intrinsics
+--------------------
+
+LLVM provides experimental intrinsics to support runtime patching
+mechanisms commonly desired in dynamic language JITs. These intrinsics
+are described in :doc:`StackMaps`.
projects / oota-llvm.git / blobdiff