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. Since this linkage exists for defining a dll interface, the
- compiler, assembler and linker know it is externally referenced and
- must refrain from deleting the symbol.
-
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:
.. _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
-----------
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``,
``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>``.
+``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
* ``m``: Mips mangling: Private symbols get a ``$`` prefix.
* ``o``: Mach-O mangling: Private symbols get ``L`` prefix. Other
symbols get a ``_`` prefix.
- * ``c``: COFF prefix: Similar to Mach-O, but stdcall and fastcall
+ * ``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
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