In addition to PGO profiling we also have limited support in-tree for generating
linker order files. These files provide the linker with a suggested ordering for
functions in the final binary layout. This can measurably speed up clang by
-physically grouping functions that are called temporally close to eachother. The
-current tooling is only available on Darwin systems with ``dtrace(1)``. It is
-worth noting that dtrace is non-deterministic, and so the order file generation
-using dtrace is also non-deterministic.
+physically grouping functions that are called temporally close to each other.
+The current tooling is only available on Darwin systems with ``dtrace(1)``. It
+is worth noting that dtrace is non-deterministic, and so the order file
+generation using dtrace is also non-deterministic.
Options for Reducing Size
=========================
b, B
- Unitialized data (bss) object.
+ Uninitialized data (bss) object.
C
ELF: Defined weak object symbol. This definition will only be used if no
regular definitions exist in a link. If multiple weak definitions and no
- regular definitons exist, one of the weak definitions will be used.
+ regular definitions exist, one of the weak definitions will be used.
w
Defined weak symbol other than an ELF object symbol. This definition will only
be used if no regular definitions exist in a link. If multiple weak definitions
- and no regular definitons exist, one of the weak definitions will be used.
+ and no regular definitions exist, one of the weak definitions will be used.
\-
disabled -- even when emitting a ``.s`` file -- and thus must contain assembly
syntax known to LLVM.
-LLVM also supports a few more substitions useful for writing inline assembly:
+LLVM also supports a few more substitutions useful for writing inline assembly:
- ``${:uid}``: Expands to a decimal integer unique to this inline assembly blob.
This substitution is useful when declaring a local label. Many standard
vFuncId: (TypeIdRef, offset: 16)
Where each ``TypeIdRef`` refers to a :ref:`type id<typeid_summary>`
-by summary id or ``GUID`` preceeded by a ``guid:`` tag.
+by summary id or ``GUID`` preceded by a ``guid:`` tag.
TypeCheckedLoadVCalls
"""""""""""""""""""""
The default behavior is to emit a call to ``__clear_cache`` from the run
time library.
-This instrinsic does *not* empty the instruction pipeline. Modifications
+This intrinsic does *not* empty the instruction pipeline. Modifications
of the current function are outside the scope of the intrinsic.
'``llvm.instrprof.increment``' Intrinsic
Semantics:
""""""""""
-See description of '``llvm.instrprof.increment``' instrinsic.
+See description of '``llvm.instrprof.increment``' intrinsic.
'``llvm.instrprof.value.profile``' Intrinsic
This document aims to provide a high-level overview of the design and
implementation of the ORC JIT APIs. Except where otherwise stated, all
-discussion applies to the design of the APIs as of LLVM verison 9 (ORCv2).
+discussion applies to the design of the APIs as of LLVM version 9 (ORCv2).
Use-cases
=========
of use cases for such an API. For example:
1. The LLVM tutorials use a simple ORC-based JIT class to execute expressions
-compiled from a toy languge: Kaleidoscope.
+compiled from a toy language: Kaleidoscope.
2. The LLVM debugger, LLDB, uses a cross-compiling JIT for expression
evaluation. In this use case, cross compilation allows expressions compiled
4. In interpreters and REPLs, e.g. Cling (C++) and the Swift interpreter.
-By adoping a modular, library-based design we aim to make ORC useful in as many
+By adopting a modular, library-based design we aim to make ORC useful in as many
of these contexts as possible.
Features
backing the definitions is an object file), or may even be a class that writes
bits directly into memory (for example, if the definitions are
stubs). Materialization is the blanket term for any actions (compiling, linking,
-splatting bits, registering with runtimes, etc.) that are requried to generate a
+splatting bits, registering with runtimes, etc.) that are required to generate a
symbol definition that is safe to call or access.
As each materializer completes its work it notifies the JITDylib, which in turn
TP.wait();
To make exclusive access to Modules easier to manage the ThreadSafeModule class
-provides a convenince function, ``withModuleDo``, that implicitly (1) locks the
+provides a convenience function, ``withModuleDo``, that implicitly (1) locks the
associated context, (2) runs a given function object, (3) unlocks the context,
and (3) returns the result generated by the function object. E.g.
the file to disk do you need to swap the value in the SuperBlock to point to
the new ``FreeBlockMapBlock``.
-The Free Block Maps are stored as a series of single blocks thoughout the file
+The Free Block Maps are stored as a series of single blocks throughout the file
at intervals of BlockSize. Because each FPM block is of size ``BlockSize``
bytes, it contains 8 times as many bits as an interval has blocks. This means
that the first block of each FPM refers to the first 8 intervals of the file
misspeculated, we need to apply this to loads in a way that ensures they do not
leak secret data. There are two primary techniques for this: we can either
harden the loaded value to prevent observation, or we can harden the address
-itself to prevent the load from occuring. These have significantly different
+itself to prevent the load from occurring. These have significantly different
performance tradeoffs.
functions. We emit it in the entry block to handle calls, and prior to each
return. This approach also has the advantage of providing the strongest degree
of mitigation when mixed with unmitigated code by halting all misspeculation
-entering a function which is mitigated, regardless of what occured in the
+entering a function which is mitigated, regardless of what occurred in the
caller. However, such a mixture is inherently more risky. Whether this kind of
mixture is a sufficient mitigation requires careful analysis.
TheJIT->removeModule(H);
}
-If parsing and codegen succeeed, the next step is to add the module containing
+If parsing and codegen succeed, the next step is to add the module containing
the top-level expression to the JIT. We do this by calling addModule, which
triggers code generation for all the functions in the module, and returns a
handle that can be used to remove the module from the JIT later. Once the module
This is a trivial case for mem2reg, since there are no redefinitions of
the variable. The point of showing this is to calm your tension about
-inserting such blatent inefficiencies :).
+inserting such blatant inefficiencies :).
After the rest of the optimizers run, we get:
projects / llvm / commitdiff