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
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
**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
LLVM provides intrinsics for a few important bit manipulation
operations. These allow efficient code generation for some algorithms.
+'``llvm.bitreverse.*``' Intrinsics
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Syntax:
+"""""""
+
+This is an overloaded intrinsic function. You can use bitreverse on any
+integer type.
+
+::
+
+ declare i16 @llvm.bitreverse.i16(i16 <id>)
+ declare i32 @llvm.bitreverse.i32(i32 <id>)
+ declare i64 @llvm.bitreverse.i64(i64 <id>)
+
+Overview:
+"""""""""
+
+The '``llvm.bitreverse``' family of intrinsics is used to reverse the
+bitpattern of an integer value; for example ``0b1234567`` becomes
+``0b7654321``.
+
+Semantics:
+""""""""""
+
+The ``llvm.bitreverse.iN`` intrinsic returns an i16 value that has bit
+``M`` in the input moved to bit ``N-M`` in the output.
+
'``llvm.bswap.*``' Intrinsics
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
projects / oota-llvm.git / blobdiff