The aliasee must be a definition.
+Aliases are not allowed to point to aliases with linkages that can be
+overridden. Since they are only a second name, the possibility of the
+intermediate alias being overridden cannot be represented in an object file.
+
.. _namedmetadatastructure:
Named Metadata
``inalloca``
-.. Warning:: This feature is unstable and not fully implemented.
-
The ``inalloca`` argument attribute allows the caller to take the
address of outgoing stack arguments. An ``inalloca`` argument must
be a pointer to stack memory produced by an ``alloca`` instruction.
not to trap and to be properly aligned. This may only be applied to
the first parameter. This is not a valid attribute for return
values.
+
+.. _noalias:
+
``noalias``
This indicates that pointer values :ref:`based <pointeraliasing>` on
the argument or return value do not alias pointer values which are
"irrelevant" to the ``noalias`` keyword for the arguments and return
value used in that call. The caller shares the responsibility with
the callee for ensuring that these requirements are met. For further
- details, please see the discussion of the NoAlias response in `alias
- analysis <AliasAnalysis.html#MustMayNo>`_.
+ details, please see the discussion of the NoAlias response in :ref:`alias
+ analysis <Must, May, or No>`.
Note that this definition of ``noalias`` is intentionally similar
to the definition of ``restrict`` in C99 for function arguments,
| ``opaque`` | An opaque type. |
+--------------+-------------------+
+.. _constants:
+
Constants
=========
"""""""""
The '``select``' instruction is used to choose one value based on a
-condition, without branching.
+condition, without IR-level branching.
Arguments:
""""""""""
Overview:
"""""""""
-The '``llvm.clear_cache``' intrinsic provides access to the systemcall
-that flushes the cache at the range specified. Some targets need this
-to specifically flush the instruction cache when executable data changes
-in memory (self-modifying code). Other targets have unified intruction
-and data cache, so they don't need any calls.
+The '``llvm.clear_cache``' intrinsic ensures visibility of modifications
+in the specified range to the execution unit of the processor. On
+targets with non-unified instruction and data cache, the implementation
+flushes the instruction cache.
Semantics:
""""""""""
-When directly supported, this intrinsic will either return a call to
-the appropriate cache clearing system call (usually ``__clear_cache``)
-when the caches are not unified (ARM, Mips) or just remove the call
-altogether when they are (ex. x86_64). Some targets can lower these
-directly into special instructions, if they have it.
+On platforms with coherent instruction and data caches (e.g. x86), this
+intrinsic is a nop. On platforms with non-coherent instruction and data
+cache (e.g. ARM, MIPS), the intrinsic is lowered either to appropriate
+instructions or a system call, if cache flushing requires special
+privileges.
-The default behaviour is to emit a call to ``__clear_cache``, so in
-case a target doesn't support it, the user gets a linker error rather
-than a compiler internal error. It also provides a work around to
-the user (implement an empty function called ``__clear_cache``) while
-LLVM doesn't implement it in the target's back-end.
+The default behavior is to emit a call to ``__clear_cache`` from the run
+time library.
-Please note that the caller is responsible for ensuring the cache
-is actually cleared. This is most important in targets that don't
-need to flush the cache directly (ex. x86_64) and could potentially
-still execute old instructions while the cache is not cleared. LLVM
-will *not* insert nops or busy-wait sequences.
+This instrinsic does *not* empty the instruction pipeline. Modifications
+of the current function are outside the scope of the intrinsic.
Standard C Library Intrinsics
-----------------------------
projects / oota-llvm.git / blobdiff