an optional :ref:`garbage collector name <gc>`, an optional :ref:`prefix <prefixdata>`,
an optional :ref:`prologue <prologuedata>`,
an optional :ref:`personality <personalityfn>`,
+an optional list of attached :ref:`metadata <metadata>`,
an opening curly brace, a list of basic blocks, and a closing curly brace.
LLVM function declarations consist of the "``declare``" keyword, an
<ResultType> @<FunctionName> ([argument list])
[unnamed_addr] [fn Attrs] [section "name"] [comdat [($name)]]
[align N] [gc] [prefix Constant] [prologue Constant]
- [personality Constant] { ... }
+ [personality Constant] (!name !N)* { ... }
The argument list is a comma separated sequence of arguments where each
argument is of the following form:
This function attribute indicates that the function never returns
normally. This produces undefined behavior at runtime if the
function ever does dynamically return.
+``norecurse``
+ This function attribute indicates that the function does not call itself
+ either directly or indirectly down any possible call path. This produces
+ undefined behavior at runtime if the function ever does recurse.
``nounwind``
This function attribute indicates that the function never raises an
exception. If the function does raise an exception, its runtime
restrictions, LLVM does not need to have special knowledge of the
operand bundle to not miscompile programs containing it.
-- The bundle operands for an unknown operand bundle escape in unknown
- ways before control is transferred to the callee or invokee.
-- Calls and invokes with operand bundles have unknown read / write
- effect on the heap on entry and exit (even if the call target is
- ``readnone`` or ``readonly``).
-- An operand bundle at a call site cannot change the implementation
- of the called function. Inter-procedural optimizations work as
- usual as long as they take into account the first two properties.
- The bundle operands for an unknown operand bundle escape in unknown
ways before control is transferred to the callee or invokee.
- Calls and invokes with operand bundles have unknown read / write
of the called function. Inter-procedural optimizations work as
usual as long as they take into account the first two properties.
+More specific types of operand bundles are described below.
+
+Deoptimization Operand Bundles
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Deoptimization operand bundles are characterized by the ``"deopt``
+operand bundle tag. These operand bundles represent an alternate
+"safe" continuation for the call site they're attached to, and can be
+used by a suitable runtime to deoptimize the compiled frame at the
+specified call site. Exact details of deoptimization is out of scope
+for the language reference, but it usually involves rewriting a
+compiled frame into a set of interpreted frames.
+
+From the compiler's perspective, deoptimization operand bundles make
+the call sites they're attached to at least ``readonly``. They read
+through all of their pointer typed operands (even if they're not
+otherwise escaped) and the entire visible heap. Deoptimization
+operand bundles do not capture their operands except during
+deoptimization, in which case control will not be returned to the
+compiled frame.
+
.. _moduleasm:
Module-Level Inline Assembly
symbols get a ``_`` prefix.
* ``w``: Windows COFF prefix: Similar to Mach-O, but stdcall and fastcall
functions also get a suffix based on the frame size.
+ * ``x``: Windows x86 COFF prefix: Similar to Windows COFF, but use a ``_``
+ prefix for ``__cdecl`` functions.
``n<size1>:<size2>:<size3>...``
This specifies a set of native integer widths for the target CPU in
bits. For example, it might contain ``n32`` for 32-bit PowerPC,
**Null pointer constants**
The identifier '``null``' is recognized as a null pointer constant
and must be of :ref:`pointer type <t_pointer>`.
+**Token constants**
+ The identifier '``none``' is recognized as an empty token constant
+ and must be of :ref:`token type <t_token>`.
The one non-intuitive notation for constants is the hexadecimal form of
floating point constants. For example, the form
call void @llvm.dbg.value(metadata !24, i64 0, metadata !25)
-Metadata can be attached with an instruction. Here metadata ``!21`` is
-attached to the ``add`` instruction using the ``!dbg`` identifier:
+Metadata can be attached to an instruction. Here metadata ``!21`` is attached
+to the ``add`` instruction using the ``!dbg`` identifier:
.. code-block:: llvm
%indvar.next = add i64 %indvar, 1, !dbg !21
+Metadata can also be attached to a function definition. Here metadata ``!22``
+is attached to the ``foo`` function using the ``!dbg`` identifier:
+
+.. code-block:: llvm
+
+ define void @foo() !dbg !22 {
+ ret void
+ }
+
More information about specific metadata nodes recognized by the
optimizers and code generator is found below.
DISubprogram
""""""""""""
-``DISubprogram`` nodes represent functions from the source language. The
-``variables:`` field points at :ref:`variables <DILocalVariable>` that must be
-retained, even if their IR counterparts are optimized out of the IR. The
-``type:`` field must point at an :ref:`DISubroutineType`.
+``DISubprogram`` nodes represent functions from the source language. A
+``DISubprogram`` may be attached to a function definition using ``!dbg``
+metadata. The ``variables:`` field points at :ref:`variables <DILocalVariable>`
+that must be retained, even if their IR counterparts are optimized out of
+the IR. The ``type:`` field must point at an :ref:`DISubroutineType`.
.. code-block:: llvm
- !0 = !DISubprogram(name: "foo", linkageName: "_Zfoov", scope: !1,
- file: !2, line: 7, type: !3, isLocal: true,
- isDefinition: false, scopeLine: 8, containingType: !4,
- virtuality: DW_VIRTUALITY_pure_virtual, virtualIndex: 10,
- flags: DIFlagPrototyped, isOptimized: true,
- function: void ()* @_Z3foov,
- templateParams: !5, declaration: !6, variables: !7)
+ define void @_Z3foov() !dbg !0 {
+ ...
+ }
+
+ !0 = distinct !DISubprogram(name: "foo", linkageName: "_Zfoov", scope: !1,
+ file: !2, line: 7, type: !3, isLocal: true,
+ isDefinition: false, scopeLine: 8,
+ containingType: !4,
+ virtuality: DW_VIRTUALITY_pure_virtual,
+ virtualIndex: 10, flags: DIFlagPrototyped,
+ isOptimized: true, templateParams: !5,
+ declaration: !6, variables: !7)
.. _DILexicalBlock:
::
- <result> = [tail | musttail] call [cconv] [ret attrs] <ty> [<fnty>*] <fnptrval>(<function args>) [fn attrs]
+ <result> = [tail | musttail | notail ] call [cconv] [ret attrs] <ty> [<fnty>*] <fnptrval>(<function args>) [fn attrs]
[ operand bundles ]
Overview:
- `Platform-specific constraints are
met. <CodeGenerator.html#tailcallopt>`_
+#. The optional ``notail`` marker indicates that the optimizers should not add
+ ``tail`` or ``musttail`` markers to the call. It is used to prevent tail
+ call optimization from being performed on the call.
+
#. The optional "cconv" marker indicates which :ref:`calling
convention <callingconv>` the call should use. If none is
specified, the call defaults to using C calling conventions. The
projects / oota-llvm.git / blobdiff