attribute for return values and can only be applied to one parameter.
``returned``
- This indicates that the value of the function always returns the value
- of the parameter as its return value. This is an optimization hint to
- the code generator when generating the caller, allowing tail call
- optimization and omission of register saves and restores in some cases;
- it is not checked or enforced when generating the callee. The parameter
- and the function return type must be valid operands for the
- :ref:`bitcast instruction <i_bitcast>`. This is not a valid attribute for
- return values and can only be applied to one parameter.
+ This indicates that the function always returns the argument as its return
+ value. This is an optimization hint to the code generator when generating
+ the caller, allowing tail call optimization and omission of register saves
+ and restores in some cases; it is not checked or enforced when generating
+ the callee. The parameter and the function return type must be valid
+ operands for the :ref:`bitcast instruction <i_bitcast>`. This is not a
+ valid attribute for return values and can only be applied to one parameter.
.. _gc:
This attribute indicates that the inliner should attempt to inline
this function into callers whenever possible, ignoring any active
inlining size threshold for this caller.
+``builtin``
+ This indicates that the callee function at a call site should be
+ recognized as a built-in function, even though the function's declaration
+ uses the ``nobuiltin`` attribute. This is only valid at call sites for
+ direct calls to functions which are declared with the ``nobuiltin``
+ attribute.
``cold``
This attribute indicates that this function is rarely called. When
computing edge weights, basic blocks post-dominated by a cold
This attribute disables prologue / epilogue emission for the
function. This can have very system-specific consequences.
``nobuiltin``
- This indicates that the callee function at a call site is not
- recognized as a built-in function. LLVM will retain the original call
- and not replace it with equivalent code based on the semantics of the
- built-in function. This is only valid at call sites, not on function
- declarations or definitions.
+ This indicates that the callee function at a call site is not recognized as
+ a built-in function. LLVM will retain the original call and not replace it
+ with equivalent code based on the semantics of the built-in function, unless
+ the call site uses the ``builtin`` attribute. This is valid at call sites
+ and on function declarations and definitions.
``noduplicate``
This attribute indicates that calls to the function cannot be
duplicated. A call to a ``noduplicate`` function may be moved
passes make choices that keep the code size of this function low,
and otherwise do optimizations specifically to reduce code size.
``readnone``
- This attribute indicates that the function computes its result (or
- decides to unwind an exception) based strictly on its arguments,
+ On a function, this attribute indicates that the function computes its
+ result (or decides to unwind an exception) based strictly on its arguments,
without dereferencing any pointer arguments or otherwise accessing
any mutable state (e.g. memory, control registers, etc) visible to
caller functions. It does not write through any pointer arguments
(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.
``readonly``
- This attribute indicates that the function does not write through
- any pointer arguments (including ``byval`` arguments) or otherwise
+ On a function, this attribute indicates that the function does not write
+ through any pointer arguments (including ``byval`` arguments) or otherwise
modify any state (e.g. memory, control registers, etc) visible to
caller functions. It may dereference pointer arguments and read
state that may be set in the caller. A readonly function always
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.
``returns_twice``
This attribute indicates that this function can return twice. The C
``setjmp`` is an example of such a function. The compiler disables
The ``@llvm.used`` global is an array which has
:ref:`appending linkage <linkage_appending>`. This array contains a list of
-pointers to global variables, functions and aliases which may optionally have a
-pointer cast formed of bitcast or getelementptr. For example, a legal
+pointers to named global variables, functions and aliases which may optionally
+have a pointer cast formed of bitcast or getelementptr. For example, a legal
use of it is:
.. code-block:: llvm
If a symbol appears in the ``@llvm.used`` list, then the compiler, assembler,
and linker are required to treat the symbol as if there is a reference to the
-symbol that it cannot see. For example, if a variable has internal linkage and
-no references other than that from the ``@llvm.used`` list, it cannot be
-deleted. This is commonly used to represent references from inline asms and
-other things the compiler cannot "see", and corresponds to
-"``attribute((used))``" in GNU C.
+symbol that it cannot see (which is why they have to be named). For example, if
+a variable has internal linkage and no references other than that from the
+``@llvm.used`` list, it cannot be deleted. This is commonly used to represent
+references from inline asms and other things the compiler cannot "see", and
+corresponds to "``attribute((used))``" in GNU C.
On some targets, the code generator must emit a directive to the
assembler or object file to prevent the assembler and linker from
may produce less efficient code. An alignment of 1 is always safe.
The optional ``!nontemporal`` metadata must reference a single
-metatadata name ``<index>`` corresponding to a metadata node with one
+metadata name ``<index>`` corresponding to a metadata node with one
``i32`` entry of value 1. The existence of the ``!nontemporal``
-metatadata on the instruction tells the optimizer and code generator
+metadata on the instruction tells the optimizer and code generator
that this load is not expected to be reused in the cache. The code
generator may select special instructions to save cache bandwidth, such
as the ``MOVNT`` instruction on x86.
The optional ``!invariant.load`` metadata must reference a single
-metatadata name ``<index>`` corresponding to a metadata node with no
-entries. The existence of the ``!invariant.load`` metatadata on the
+metadata name ``<index>`` corresponding to a metadata node with no
+entries. The existence of the ``!invariant.load`` metadata on the
instruction tells the optimizer and code generator that this load
address points to memory which does not change value during program
execution. The optimizer may then move this load around, for example, by
alignment may produce less efficient code. An alignment of 1 is always
safe.
-The optional ``!nontemporal`` metadata must reference a single metatadata
+The optional ``!nontemporal`` metadata must reference a single metadata
name ``<index>`` corresponding to a metadata node with one ``i32`` entry of
-value 1. The existence of the ``!nontemporal`` metatadata on the instruction
+value 1. The existence of the ``!nontemporal`` metadata on the instruction
tells the optimizer and code generator that this load is not expected to
be reused in the cache. The code generator may select special
instructions to save cache bandwidth, such as the MOVNT instruction on
projects / oota-llvm.git / blobdiff