aboutsummaryrefslogtreecommitdiff
path: root/llvm/docs/BitCodeFormat.rst
diff options
context:
space:
mode:
authorPeter Collingbourne <peter@pcc.me.uk>2014-12-03 02:08:38 +0000
committerPeter Collingbourne <peter@pcc.me.uk>2014-12-03 02:08:38 +0000
commit51d2de7b9edfb8e5aad0c533c249b16989a9af41 (patch)
treebeb252c6d4c847126fcb191cc5e2a79a5e97e227 /llvm/docs/BitCodeFormat.rst
parent4c71cc1dcb57d1beb5acbd5fdb0cba7e8c246a48 (diff)
downloadllvm-51d2de7b9edfb8e5aad0c533c249b16989a9af41.zip
llvm-51d2de7b9edfb8e5aad0c533c249b16989a9af41.tar.gz
llvm-51d2de7b9edfb8e5aad0c533c249b16989a9af41.tar.bz2
Prologue support
Patch by Ben Gamari! This redefines the `prefix` attribute introduced previously and introduces a `prologue` attribute. There are a two primary usecases that these attributes aim to serve, 1. Function prologue sigils 2. Function hot-patching: Enable the user to insert `nop` operations at the beginning of the function which can later be safely replaced with a call to some instrumentation facility 3. Runtime metadata: Allow a compiler to insert data for use by the runtime during execution. GHC is one example of a compiler that needs this functionality for its tables-next-to-code functionality. Previously `prefix` served cases (1) and (2) quite well by allowing the user to introduce arbitrary data at the entrypoint but before the function body. Case (3), however, was poorly handled by this approach as it required that prefix data was valid executable code. Here we redefine the notion of prefix data to instead be data which occurs immediately before the function entrypoint (i.e. the symbol address). Since prefix data now occurs before the function entrypoint, there is no need for the data to be valid code. The previous notion of prefix data now goes under the name "prologue data" to emphasize its duality with the function epilogue. The intention here is to handle cases (1) and (2) with prologue data and case (3) with prefix data. References ---------- This idea arose out of discussions[1] with Reid Kleckner in response to a proposal to introduce the notion of symbol offsets to enable handling of case (3). [1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/073235.html Test Plan: testsuite Differential Revision: http://reviews.llvm.org/D6454 llvm-svn: 223189
Diffstat (limited to 'llvm/docs/BitCodeFormat.rst')
-rw-r--r--llvm/docs/BitCodeFormat.rst10
1 files changed, 8 insertions, 2 deletions
diff --git a/llvm/docs/BitCodeFormat.rst b/llvm/docs/BitCodeFormat.rst
index 34485b5..fc553f7 100644
--- a/llvm/docs/BitCodeFormat.rst
+++ b/llvm/docs/BitCodeFormat.rst
@@ -741,7 +741,7 @@ global variable. The operand fields are:
MODULE_CODE_FUNCTION Record
^^^^^^^^^^^^^^^^^^^^^^^^^^^
-``[FUNCTION, type, callingconv, isproto, linkage, paramattr, alignment, section, visibility, gc, prefix, dllstorageclass]``
+``[FUNCTION, type, callingconv, isproto, linkage, paramattr, alignment, section, visibility, gc, prologuedata, dllstorageclass, comdat, prefixdata]``
The ``FUNCTION`` record (code 8) marks the declaration or definition of a
function. The operand fields are:
@@ -784,12 +784,18 @@ function. The operand fields are:
* *unnamed_addr*: If present and non-zero, indicates that the function has
``unnamed_addr``
-* *prefix*: If non-zero, the value index of the prefix data for this function,
+* *prologuedata*: If non-zero, the value index of the prologue data for this function,
plus 1.
* *dllstorageclass*: An encoding of the
:ref:`dllstorageclass<bcdllstorageclass>` of this function
+* *comdat*: An encoding of the COMDAT of this function
+
+* *prefixdata*: If non-zero, the value index of the prefix data for this function,
+ plus 1.
+
+
MODULE_CODE_ALIAS Record
^^^^^^^^^^^^^^^^^^^^^^^^