|
@@ -552,16 +552,16 @@ an optional ``unnamed_addr`` attribute, a return type, an optional
|
|
|
name, a (possibly empty) argument list (each with optional :ref:`parameter
|
|
|
attributes <paramattrs>`), optional :ref:`function attributes <fnattrs>`,
|
|
|
an optional section, an optional alignment, an optional :ref:`garbage
|
|
|
-collector name <gc>`, an opening curly brace, a list of basic blocks,
|
|
|
-and a closing curly brace.
|
|
|
+collector name <gc>`, an optional :ref:`prefix <prefixdata>`, an opening
|
|
|
+curly brace, a list of basic blocks, and a closing curly brace.
|
|
|
|
|
|
LLVM function declarations consist of the "``declare``" keyword, an
|
|
|
optional :ref:`linkage type <linkage>`, an optional :ref:`visibility
|
|
|
style <visibility>`, an optional :ref:`calling convention <callingconv>`,
|
|
|
an optional ``unnamed_addr`` attribute, a return type, an optional
|
|
|
:ref:`parameter attribute <paramattrs>` for the return type, a function
|
|
|
-name, a possibly empty list of arguments, an optional alignment, and an
|
|
|
-optional :ref:`garbage collector name <gc>`.
|
|
|
+name, a possibly empty list of arguments, an optional alignment, an optional
|
|
|
+:ref:`garbage collector name <gc>` and an optional :ref:`prefix <prefixdata>`.
|
|
|
|
|
|
A function definition contains a list of basic blocks, forming the CFG
|
|
|
(Control Flow Graph) for the function. Each basic block may optionally
|
|
@@ -598,7 +598,7 @@ Syntax::
|
|
|
[cconv] [ret attrs]
|
|
|
<ResultType> @<FunctionName> ([argument list])
|
|
|
[fn Attrs] [section "name"] [align N]
|
|
|
- [gc] { ... }
|
|
|
+ [gc] [prefix Constant] { ... }
|
|
|
|
|
|
.. _langref_aliases:
|
|
|
|
|
@@ -757,6 +757,50 @@ The compiler declares the supported values of *name*. Specifying a
|
|
|
collector which will cause the compiler to alter its output in order to
|
|
|
support the named garbage collection algorithm.
|
|
|
|
|
|
+.. _prefixdata:
|
|
|
+
|
|
|
+Prefix Data
|
|
|
+-----------
|
|
|
+
|
|
|
+Prefix data is data associated with a function which the code generator
|
|
|
+will emit immediately before the function body. The purpose of this feature
|
|
|
+is to allow frontends to associate language-specific runtime metadata with
|
|
|
+specific functions and make it available through the function pointer while
|
|
|
+still allowing the function pointer to be called. To access the data for a
|
|
|
+given function, a program may bitcast the function pointer to a pointer to
|
|
|
+the constant's type. This implies that the IR symbol points to the start
|
|
|
+of the prefix data.
|
|
|
+
|
|
|
+To maintain the semantics of ordinary function calls, the prefix data must
|
|
|
+have a particular format. Specifically, it must begin with a sequence of
|
|
|
+bytes which decode to a sequence of machine instructions, valid for the
|
|
|
+module's target, which transfer control to the point immediately succeeding
|
|
|
+the prefix data, without performing any other visible action. This allows
|
|
|
+the inliner and other passes to reason about the semantics of the function
|
|
|
+definition without needing to reason about the prefix data. Obviously this
|
|
|
+makes the format of the prefix data highly target dependent.
|
|
|
+
|
|
|
+A trivial example of valid prefix data for the x86 architecture is ``i8 144``,
|
|
|
+which encodes the ``nop`` instruction:
|
|
|
+
|
|
|
+.. code-block:: llvm
|
|
|
+
|
|
|
+ define void @f() prefix i8 144 { ... }
|
|
|
+
|
|
|
+Generally prefix data can be formed by encoding a relative branch instruction
|
|
|
+which skips the metadata, as in this example of valid prefix data for the
|
|
|
+x86_64 architecture, where the first two bytes encode ``jmp .+10``:
|
|
|
+
|
|
|
+.. code-block:: llvm
|
|
|
+
|
|
|
+ %0 = type <{ i8, i8, i8* }>
|
|
|
+
|
|
|
+ define void @f() prefix %0 <{ i8 235, i8 8, i8* @md}> { ... }
|
|
|
+
|
|
|
+A function may have prefix data but no body. This has similar semantics
|
|
|
+to the ``available_externally`` linkage in that the data may be used by the
|
|
|
+optimizers but will not be emitted in the object file.
|
|
|
+
|
|
|
.. _attrgrp:
|
|
|
|
|
|
Attribute Groups
|