so that the call does not break any live ranges in the caller side.
This calling convention does not support varargs and requires the
prototype of all callees to exactly match the prototype of the
- function definition.
+ function definition. Furthermore the inliner doesn't consider such function
+ calls for inlining.
"``cc 10``" - GHC convention
This calling convention has been implemented specifically for use by
the `Glasgow Haskell Compiler (GHC) <http://www.haskell.org/ghc>`_.
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
that have a hot path and a cold path. The hot path is usually a small piece
of code that doesn't many registers. The cold path might need to call out to
another function and therefore only needs to preserve the caller-saved
- registers, which haven't already been saved by the caller.
+ registers, which haven't already been saved by the caller. The
+ `PreserveMost` calling convention is very similar to the `cold` calling
+ convention in terms of caller/callee-saved registers, but they are used for
+ different types of function calls. `coldcc` is for function calls that are
+ rarely executed, whereas `preserve_mostcc` function calls are intended to be
+ on the hot path and definitely executed a lot. Furthermore `preserve_mostcc`
+ doesn't prevent the inliner from inlining the function call.
This calling convention will be used by a future version of the ObjectiveC
runtime and should therefore still be considered experimental at this time.
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
.. 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
::
- <result> = alloca <type>[, <ty> <NumElements>][, align <alignment>] ; yields {type*}:result
+ <result> = alloca <type>[,
inalloca][, <ty> <NumElements>][, align <alignment>] ; yields {type*}:result
Overview:
"""""""""
""""""""""
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