Lines Matching refs:JITDylib

188   // Create JITDylib "A" and add code to it using the CXX layer.
193   // Create JITDylib "B" and add code to it using the CXX layer.
198   // Create and specify the search order for the main JITDylib. This is
224 all of their code in a single JITDylib. However, clients who want to JIT code
251 As each materializer completes its work it notifies the JITDylib, which in turn
285   which is then stored in the JITDylib. MaterializationUnits are responsible for
296   that must be materialized and provides a way to notify the JITDylib once they
395 JITDylib. The ``reexports`` function provides the same functionality, but
396 operates across JITDylib boundaries. E.g.
409 The reexports utility can be handy for composing a single JITDylib interface by
444 If JITDylib ``JD`` contains definitions for symbols ``foo_body`` and
445 ``bar_body``, we can create lazy entry points ``Foo`` and ``Bar`` in JITDylib
488      directly to JIT classes or layers. Instead, they are added to ``JITDylib``
489      instances *by* layers. The ``JITDylib`` determines *where* the definitions
496      clients should place all code in a single JITDylib.
498      code in LLJIT's default created main JITDylib (See
515      ``lookup`` method on JITDylib that takes a list of JITDylibs to scan.
520        JITDylib &JD1 = ...;
521        JITDylib &JD2 = ...;
579 The JITDylib is owned by the ``ExecutionEngine`` instance and will be freed
698 be added to a JITDylib that the JIT'd definitions link against.
718 *definition generators*. If a definition generator is attached to a JITDylib,
719 then any unsuccessful lookup on that JITDylib will fall back to calling the
793    The core ORC state machine is currently implemented between JITDylib and
797    ExecutionSession and leaving the JITDylib instance in a defunct state until