private to be renamed as necessary to avoid collisions. Because the
symbol is private to the module, all references can be updated. This
doesn't show up in any symbol table in the object file.
-``linker_private``
- Similar to ``private``, but the symbol is passed through the
- assembler and evaluated by the linker. Unlike normal strong symbols,
- they are removed by the linker from the final linked image
- (executable or dynamic library).
-``linker_private_weak``
- Similar to "``linker_private``", but the symbol is weak. Note that
- ``linker_private_weak`` symbols are subject to coalescing by the
- linker. The symbols are removed by the linker from the final linked
- image (executable or dynamic library).
``internal``
Similar to private, but the value shows as a local symbol
(``STB_LOCAL`` in the case of ELF) in the object file. This
calling convention on how arguments and return values are passed, but it
uses a different set of caller/callee-saved registers. This alleviates the
burden of saving and recovering a large register set before and after the
- call in the caller.
+ call in the caller. If the arguments are passed in callee-saved registers,
+ then they will be preserved by the callee across the call. This doesn't
+ apply for values returned in callee-saved registers.
- On X86-64 the callee preserves all general purpose registers, except for
R11. R11 can be used as a scratch register. Floating-point registers
convention also behaves identical to the `C` calling convention on how
arguments and return values are passed, but it uses a different set of
caller/callee-saved registers. This removes the burden of saving and
- recovering a large register set before and after the call in the caller.
+ recovering a large register set before and after the call in the caller. If
+ the arguments are passed in callee-saved registers, then they will be
+ preserved by the callee across the call. This doesn't apply for values
+ returned in callee-saved registers.
- On X86-64 the callee preserves all general purpose registers, except for
R11. R11 can be used as a scratch register. Furthermore it also preserves
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
------------
+Structure Types
+---------------
+
+LLVM IR allows you to specify both "identified" and "literal" :ref:`structure
+types <t_struct>`. Literal types are uniqued structurally, but identified types
+are never uniqued. An :ref:`opaque structural type <t_opaque>` can also be used
+to forward declare a type which is not yet available.
-LLVM IR allows you to specify name aliases for certain types. This can
-make it easier to read the IR and make the IR more condensed
-(particularly when recursive types are involved). An example of a name
-specification is:
+An example of a identified structure specification is:
.. code-block:: llvm
%mytype = type { %mytype*, i32 }
-You may give a name to any :ref:`type <typesystem>` except
-":ref:`void <t_void>`". Type name aliases may be used anywhere a type is
-expected with the syntax "%mytype".
-
-Note that type names are aliases for the structural type that they
-indicate, and that you can therefore specify multiple names for the same
-type. This often leads to confusing behavior when dumping out a .ll
-file. Since LLVM IR uses structural typing, the name is not part of the
-type. When printing out LLVM IR, the printer will pick *one name* to
-render all types of a particular shape. This means that if you have code
-where two different source types end up having the same LLVM type, that
-the dumper will sometimes print the "wrong" or unexpected type. This is
-an important design point and isn't going to change.
+Prior to the LLVM 3.0 release, identified types were structurally uniqued. Only
+literal types are uniqued in recent versions of LLVM.
.. _globalvars:
define [linkage] [visibility] [DLLStorageClass]
[cconv] [ret attrs]
<ResultType> @<FunctionName> ([argument list])
- [fn Attrs] [section "name"] [align N]
+ [unnamed_addr] [fn Attrs] [section "name"] [align N]
[gc] [prefix Constant] { ... }
.. _langref_aliases:
@<Name> = [Visibility] [DLLStorageClass] alias [Linkage] <AliaseeTy> @<Aliasee>
-The linkage must be one of ``private``, ``linker_private``,
-``linker_private_weak``, ``internal``, ``linkonce``, ``weak``,
+The linkage must be one of ``private``, ``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.
+Alias that are not ``unnamed_addr`` are guaranteed to have the same address as
+the aliasee.
+
+The aliasee must be a definition.
+
.. _namedmetadatastructure:
Named Metadata
.. Warning:: This feature is unstable and not fully implemented.
The ``inalloca`` argument attribute allows the caller to take the
- address of all stack-allocated arguments 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>`, an alloca may be used as an
- ``inalloca`` argument at most once. The attribute can only be
- applied to the last parameter, and it guarantees that they are
- passed in memory. 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``.
+ address of outgoing stack arguments. An ``inalloca`` argument must
+ be a pointer to stack memory produced by an ``alloca`` instruction.
+ The alloca, or argument allocation, must also be tagged with the
+ inalloca keyword. Only the past argument may have the ``inalloca``
+ attribute, and that argument is guaranteed to be passed in memory.
+
+ An argument allocation may be used by a call at most once because
+ the call may deallocate it. The ``inalloca`` attribute cannot be
+ used in conjunction with other attributes that affect argument
+ storage, like ``inreg``, ``nest``, ``sret``, or ``byval``. The
+ ``inalloca`` attribute also disables LLVM's implicit lowering of
+ large aggregate return values, which means that frontend authors
+ must lower them with ``sret`` pointers.
When the call site is reached, the argument allocation must have
been the most recent stack allocation that is still live, or the
- Calls to alloca() with variable sizes or constant sizes greater than
``ssp-buffer-size``.
+ Variables that are identified as requiring a protector will be arranged
+ on the stack such that they are adjacent to the stack protector guard.
+
If a function that has an ``ssp`` attribute is inlined into a
function that doesn't have an ``ssp`` attribute, then the resulting
function will have an ``ssp`` attribute.
stack smashing protector. This overrides the ``ssp`` function
attribute.
+ Variables that are identified as requiring a protector will be arranged
+ on the stack such that they are adjacent to the stack protector guard.
+ The specific layout rules are:
+
+ #. Large arrays and structures containing large arrays
+ (``>= ssp-buffer-size``) are closest to the stack protector.
+ #. Small arrays and structures containing small arrays
+ (``< ssp-buffer-size``) are 2nd closest to the protector.
+ #. Variables that have had their address taken are 3rd closest to the
+ protector.
+
If a function that has an ``sspreq`` attribute is inlined into a
function that doesn't have an ``sspreq`` attribute or which has an
``ssp`` or ``sspstrong`` attribute, then the resulting function will have
- Calls to alloca().
- Local variables that have had their address taken.
+ Variables that are identified as requiring a protector will be arranged
+ on the stack such that they are adjacent to the stack protector guard.
+ The specific layout rules are:
+
+ #. Large arrays and structures containing large arrays
+ (``>= ssp-buffer-size``) are closest to the stack protector.
+ #. Small arrays and structures containing small arrays
+ (``< ssp-buffer-size``) are 2nd closest to the protector.
+ #. Variables that have had their address taken are 3rd closest to the
+ protector.
+
This overrides the ``ssp`` function attribute.
If a function that has an ``sspstrong`` attribute is inlined into a
Atomic instructions (:ref:`cmpxchg <i_cmpxchg>`,
:ref:`atomicrmw <i_atomicrmw>`, :ref:`fence <i_fence>`,
:ref:`atomic load <i_load>`, and :ref:`atomic store <i_store>`) take
-an ordering parameter that determines which other atomic instructions on
+ordering parameters that determine which other atomic instructions on
the same address they *synchronize with*. These semantics are borrowed
from Java and C++0x, but are somewhat more colloquial. If these
descriptions aren't precise enough, check those specs (see spec
* - ``ppc_fp128``
- 128-bit floating point value (two 64-bits)
-.. _t_x86mmx:
-
-X86mmx Type
-"""""""""""
+X86_mmx Type
+""""""""""""
:Overview:
-The x86mmx type represents a value held in an MMX register on an x86
+The x86_mmx type represents a value held in an MMX register on an x86
machine. The operations allowed on it are quite limited: parameters and
return values, load and store, and bitcast. User-specified MMX
instructions are represented as intrinsic or asm calls with arguments
::
- x86mmx
+ x86_mmx
.. _t_pointer:
followed by 4 hexadecimal digits. All hexadecimal formats are big-endian
(sign bit at the left).
-There are no constants of type x86mmx.
+There are no constants of type x86_mmx.
.. _complexconstants:
for.body:
...
- %0 = load i32* %arrayidx, align 4, !llvm.mem.parallel_loop_access !0
+ %val0 = load i32* %arrayidx, !llvm.mem.parallel_loop_access !0
...
- store i32 %0, i32* %arrayidx4, align 4, !llvm.mem.parallel_loop_access !0
+ store i32 %val0, i32* %arrayidx1, !llvm.mem.parallel_loop_access !0
...
br i1 %exitcond, label %for.end, label %for.body, !llvm.loop !0
.. code-block:: llvm
outer.for.body:
- ...
+ ...
+ %val1 = load i32* %arrayidx3, !llvm.mem.parallel_loop_access !2
+ ...
+ br label %inner.for.body
inner.for.body:
...
- %0 = load i32* %arrayidx, align 4, !llvm.mem.parallel_loop_access !0
+ %val0 = load i32* %arrayidx1, !llvm.mem.parallel_loop_access !0
...
- store i32 %0, i32* %arrayidx4, align 4, !llvm.mem.parallel_loop_access !0
+ store i32 %val0, i32* %arrayidx2, !llvm.mem.parallel_loop_access !0
...
br i1 %exitcond, label %inner.for.end, label %inner.for.body, !llvm.loop !1
inner.for.end:
...
- %0 = load i32* %arrayidx, align 4, !llvm.mem.parallel_loop_access !0
- ...
- store i32 %0, i32* %arrayidx4, align 4, !llvm.mem.parallel_loop_access !0
+ store i32 %val1, i32* %arrayidx4, !llvm.mem.parallel_loop_access !2
...
br i1 %exitcond, label %outer.for.end, label %outer.for.body, !llvm.loop !2
::
- <result> = alloca
<type>[, <ty> <NumElements>][, align <alignment>] ; yields {type*}:result
+ <result> = alloca
[inalloca] <type> [, <ty> <NumElements>] [, align <alignment>] ; yields {type*}:result
Overview:
"""""""""
::
- cmpxchg [volatile] <ty>* <pointer>, <ty> <cmp>, <ty> <new> [singlethread] <ordering> ; yields {ty}
+ cmpxchg [volatile] <ty>* <pointer>, <ty> <cmp>, <ty> <new> [singlethread] <success ordering> <failure ordering> ; yields {ty}
Overview:
"""""""""
to modify the number or order of execution of this ``cmpxchg`` with
other :ref:`volatile operations <volatile>`.
-The :ref:`ordering <ordering>` argument specifies how this ``cmpxchg``
-synchronizes with other atomic operations.
+The success and failure :ref:`ordering <ordering>` arguments specify how this
+``cmpxchg`` synchronizes with other atomic operations. The both ordering
+parameters must be at least ``monotonic``, the ordering constraint on failure
+must be no stronger than that on success, and the failure ordering cannot be
+either ``release`` or ``acq_rel``.
The optional "``singlethread``" argument declares that the ``cmpxchg``
is only atomic with respect to code (usually signal handlers) running in
equal, '``<new>``' is written. The original value at the location is
returned.
-A successful ``cmpxchg`` is a read-modify-write instruction for the purpose
-of identifying release sequences. A failed ``cmpxchg`` is equivalent to an
-atomic load with an ordering parameter determined by dropping any
-``release`` part of the ``cmpxchg``'s ordering.
+A successful ``cmpxchg`` is a read-modify-write instruction for the purpose of
+identifying release sequences. A failed ``cmpxchg`` is equivalent to an atomic
+load with an ordering parameter determined the second ordering parameter.
Example:
""""""""
loop:
%cmp = phi i32 [ %orig, %entry ], [%old, %loop]
%squared = mul i32 %cmp, %cmp
- %old = cmpxchg i32* %ptr, i32 %cmp, i32 %squared ; yields {i32}
+ %old = cmpxchg i32* %ptr, i32 %cmp, i32 %squared acq_rel monotonic ; yields {i32}
%success = icmp eq i32 %cmp, %old
br i1 %success, label %done, label %loop
""""""""""
This function returns the same values as the libm ``fma`` functions
-would.
+would, and does not set errno.
'``llvm.fabs.*``' Intrinsic
^^^^^^^^^^^^^^^^^^^^^^^^^^^
not be performed between the multiplication and addition steps if the
code generator fuses the operations. Fusion is not guaranteed, even if
the target platform supports it. If a fused multiply-add is required the
-corresponding llvm.fma.\* intrinsic function should be used instead.
+corresponding llvm.fma.\* intrinsic function should be used
+instead. This never sets errno, just as '``llvm.fma.*``'.
Examples:
"""""""""
Syntax:
"""""""
+This is an overloaded intrinsic. You can use ``llvm.expect`` on any
+integer bit width.
+
::
+ declare i1 @llvm.expect.i1(i1 <val>, i1 <expected_val>)
declare i32 @llvm.expect.i32(i32 <val>, i32 <expected_val>)
declare i64 @llvm.expect.i64(i64 <val>, i64 <expected_val>)
projects / oota-llvm.git / blobdiff