``linkonce_odr`` and ``weak_odr`` linkage types to indicate that the
global will only be merged with equivalent globals. These linkage
types are otherwise the same as their non-``odr`` versions.
-``linkonce_odr_auto_hide``
- Similar to "``linkonce_odr``", but nothing in the translation unit
- takes the address of this definition. For instance, functions that
- had an inline definition, but the compiler decided not to inline it.
- ``linkonce_odr_auto_hide`` may have only ``default`` visibility. The
- symbols are removed by the linker from the final linked image
- (executable or dynamic library).
``external``
If none of the above identifiers are used, the global is externally
visible, meaning that it participates in linkage and can be used to
It is illegal for a function *declaration* to have any linkage type
other than ``external``, ``dllimport`` or ``extern_weak``.
-Aliases can have only ``external``, ``internal``, ``weak`` or
-``weak_odr`` linkages.
-
.. _callingconv:
Calling Conventions
----------------
Global variables define regions of memory allocated at compilation time
-instead of run-time. Global variables may optionally be initialized, may
-have an explicit section to be placed in, and may have an optional
-explicit alignment specified.
+instead of run-time.
+
+Global variables definitions must be initialized, may have an explicit section
+to be placed in, and may have an optional explicit alignment specified.
+
+Global variables in other translation units can also be declared, in which
+case they don't have an initializer.
A variable may be defined as ``thread_local``, which means that it will
not be shared by threads (each thread will have a separated copy of the
@G = addrspace(5) constant float 1.0, section "foo", align 4
+The following example just declares a global variable
+
+.. code-block:: llvm
+
+ @G = external global i32
+
The following example defines a thread-local global with the
``initialexec`` TLS model:
name, a possibly empty list of arguments, an optional alignment, an optional
:ref:`garbage collector name <gc>` and an optional :ref:`prefix <prefixdata>`.
-A function definition contains a list of basic blocks, forming the CFG
-(Control Flow Graph) for the function. Each basic block may optionally
-start with a label (giving the basic block a symbol table entry),
-contains a list of instructions, and ends with a
-:ref:`terminator <terminators>` instruction (such as a branch or function
-return). If explicit label is not provided, a block is assigned an
-implicit numbered label, using a next value from the same counter as used
-for unnamed temporaries (:ref:`see above<identifiers>`). For example, if a
-function entry block does not have explicit label, it will be assigned
-label "%0", then first unnamed temporary in that block will be "%1", etc.
+A function definition contains a list of basic blocks, forming the CFG (Control
+Flow Graph) for the function. Each basic block may optionally start with a label
+(giving the basic block a symbol table entry), contains a list of instructions,
+and ends with a :ref:`terminator <terminators>` instruction (such as a branch or
+function return). If an explicit label is not provided, a block is assigned an
+implicit numbered label, using the next value from the same counter as used for
+unnamed temporaries (:ref:`see above<identifiers>`). For example, if a function
+entry block does not have an explicit label, it will be assigned label "%0",
+then the first unnamed temporary in that block will be "%1", etc.
The first basic block in a function is special in two ways: it is
immediately executed on entrance to the function, and it is not allowed
@<Name> = alias [Linkage] [Visibility] <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
+alias.
+
.. _namedmetadatastructure:
Named Metadata
definition without needing to reason about the prefix data. Obviously this
makes the format of the prefix data highly target dependent.
+Prefix data is laid out as if it were an initializer for a global variable
+of the prefix data's type. No padding is automatically placed between the
+prefix data and the function body. If padding is required, it must be part
+of the prefix data.
+
A trivial example of valid prefix data for the x86 architecture is ``i8 144``,
which encodes the ``nop`` instruction:
``minsize``
This attribute suggests that optimization passes and code generator
passes make choices that keep the code size of this function as small
- as possible and perform optimizations that may sacrifice runtime
+ as possible and perform optimizations that may sacrifice runtime
performance in order to minimize the size of the generated code.
``naked``
This attribute disables prologue / epilogue emission for the
unwind, its runtime behavior is undefined.
``optnone``
This function attribute indicates that the function is not optimized
- by any optimization or code generator passes with the
+ by any optimization or code generator passes with the
exception of interprocedural optimization passes.
This attribute cannot be used together with the ``alwaysinline``
attribute; this attribute is also incompatible
with the ``minsize`` attribute and the ``optsize`` attribute.
-
+
The inliner should never inline this function in any situation.
Only functions with the ``alwaysinline`` attribute are valid
candidates for inlining inside the body of this function.
(including ``byval`` arguments) and never changes any state visible
to callers. This means that it cannot unwind exceptions by calling
the ``C++`` exception throwing methods.
-
+
On an argument, this attribute indicates that the function does not
dereference that pointer argument, even though it may read or write the
memory that the pointer points to if accessed through other pointers.
called with the same set of arguments and global state. It cannot
unwind an exception by calling the ``C++`` exception throwing
methods.
-
+
On an argument, this attribute indicates that the function does not write
through this pointer argument, even though it may write to the memory that
the pointer points to.
that require precise layout information, but this also prevents those
optimizations from introducing target specificity into the IR.
+.. _langref_triple:
+
+Target Triple
+-------------
+
+A module may specify a target triple string that describes the target
+host. The syntax for the target triple is simply:
+
+.. code-block:: llvm
+
+ target triple = "x86_64-apple-macosx10.7.0"
+
+The *target triple* string consists of a series of identifiers delimited
+by the minus sign character ('-'). The canonical forms are:
+
+::
+
+ ARCHITECTURE-VENDOR-OPERATING_SYSTEM
+ ARCHITECTURE-VENDOR-OPERATING_SYSTEM-ENVIRONMENT
+
+This information is passed along to the backend so that it generates
+code for the proper architecture. It's possible to override this on the
+command line with the ``-mtriple`` command line option.
+
.. _pointeraliasing:
Pointer Aliasing Rules
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 first class type or a void type.
+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>`.
+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:
"""""""""
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 be aligned to some boundary, this can be specified as the fourth
-argument, otherwise it should be set to 0 or 1.
+argument, otherwise it should be set to 0 or 1 (both meaning no alignment).
'``llvm.memmove``' Intrinsic
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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 boundary, this can be specified as the fourth argument,
-otherwise it should be set to 0 or 1.
+otherwise it should be set to 0 or 1 (both meaning no alignment).
'``llvm.memset.*``' Intrinsics
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The '``llvm.memset.*``' intrinsics fill "len" bytes of memory starting
at the destination location. If the argument is known to be aligned to
some boundary, this can be specified as the fourth argument, otherwise
-it should be set to 0 or 1.
+it should be set to 0 or 1 (both meaning no alignment).
'``llvm.sqrt.*``' Intrinsic
^^^^^^^^^^^^^^^^^^^^^^^^^^^
handle the success/failure cases. This makes it difficult to stop the stack
protector check from disrupting sibling tail calls in Codegen. With this
intrinsic, we are able to generate the stack protector basic blocks late in
-codegen after the tail call decision has occured.
+codegen after the tail call decision has occurred.
'``llvm.objectsize``' Intrinsic
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
projects / oota-llvm.git / blobdiff