Lines Matching refs:JIT
12 implementation of the ORC JIT APIs. Except where otherwise stated all discussion
19 ORC provides a modular API for building JIT compilers. There are a number
22 1. The LLVM tutorials use a simple ORC-based JIT class to execute expressions
25 2. The LLVM debugger, LLDB, uses a cross-compiling JIT for expression
31 optimizations within an existing JIT infrastructure.
43 **JIT-linking**
46 that contains the JIT session object and jit-linker, or may be another process
48 with the JIT via RPC.
52 ConcurrentIRCompiler) that make it easy to add LLVM IR to a JIT'd process.
55 By default, ORC will compile symbols as soon as they are looked up in the JIT
57 easy to use ORC as an in-memory compiler for an existing JIT (similar to how
63 JIT session. ORC will run the user-supplied compiler when the a definition of
68 **Concurrent JIT'd code** and **Concurrent Compilation**
69 JIT'd code may be executed in multiple threads, may spawn new threads, and may
73 ORC does not release pointers to JIT'd code or data until all dependencies
74 have also been JIT'd and they are safe to call or use.
77 Resources for JIT'd program representations
81 ORC components together to make a non-lazy, in-process, single threaded JIT
82 or a lazy, out-of-process, concurrent JIT, or anything in between.
87 ORC provides two basic JIT classes off-the-shelf. These are useful both as
88 examples of how to assemble ORC components to make a JIT, and as replacements
89 for earlier LLVM JIT APIs (e.g. MCJIT).
102 JIT API.
111 auto JIT = LLJITBuilder().create();
114 if (!JIT)
115 return JIT.takeError();
118 if (auto Err = JIT->addIRModule(TheadSafeModule(std::move(M), Ctx)))
121 // Look up the JIT'd code entry point.
122 auto EntrySym = JIT->lookup("entry");
129 // Call into JIT'd code.
133 specified before the JIT instance is constructed. For example:
142 // JIT'd code will jump here if lazy compilation fails, giving us an
143 // opportunity to exit or throw an exception into JIT'd code.
147 auto JIT = LLLazyJITBuilder()
161 ORC's JIT program model aims to emulate the linking and symbol resolution
162 rules used by the static and dynamic linkers. This allows ORC to JIT
205 // Look up the JIT'd main, cast it to a function pointer, then call it.
222 Many JIT clients will have no need for this strict adherence to the usual
224 all of their code in a single JITDylib. However, clients who want to JIT code
270 - *ExecutionSession* represents the JIT'd program and provides context for the
271 JIT: It contains the JITDylibs, error reporting mechanisms, and dispatches the
280 Several other important APIs are used explicitly. JIT clients need not be aware
320 With this mapping established code added to the JIT can refer to printf
322 This in turn allows cached versions of the JIT'd code (e.g. compiled objects)
323 to be re-used across JIT sessions as the JIT'd code no longer changes, only the
330 for making non-global objects in your JIT visible to JIT'd code. For example,
331 imagine that your JIT standard library needs access to your JIT object to make
337 // From standard library for JIT'd code:
346 We can turn this into a symbolic reference in the JIT standard library:
354 And then make our JIT object visible to the JIT standard library with an
355 absolute symbol definition when the JIT is started:
374 JIT'd code has access to a log function, ``void log(const char*)`` for which
375 there are two implementations in the JIT standard library: ``log_fast`` and
376 ``log_detailed``. Your JIT can choose which one of these definitions will be
377 used when the ``log`` symbol is referenced by setting up an alias at JIT startup
423 JIT. If the stub is called at runtime then the lazy call-through will look up
432 compilation, concurrent JIT'd code, and speculative compilation.
472 concurrent JIT compilation. The new APIs (including new layer interfaces and
486 1. ORCv2 fully adopts the JIT-as-linker model that began with MCJIT. Modules
488 directly to JIT classes or layers. Instead, they are added to ``JITDylib``
501 2. All JIT stacks now need an ``ExecutionSession`` instance. ExecutionSession
689 JIT'd code typically needs access to symbols in the host program or in
692 constants, however this ties the JIT'd code to the current process's virtual
697 allow the JIT linker to find these external definitions their addresses must
698 be added to a JITDylib that the JIT'd definitions link against.
777 The ``TargetProcessControl`` API provides various operations on the JIT
778 target process (the one which will execute the JIT'd code), including
807 1. **ORC JIT Runtime Libraries**
809 We need a runtime library for JIT'd code. This would include things like
811 (e.g. Objective C and Swift) and other JIT specific runtime code. This should
817 like JIT'd code to be able to "dlopen" and "dlclose" JITDylibs, running all of
824 as the underlying JIT linker. We will need a new solution for JITLink based
833 *speculative* JIT compilation: compilation of code that is not needed yet,
835 used to hide compile latency and improve JIT throughput. A proof-of-concept
850 ``RemoteObjectServerLayer`` means that JIT stacks can no longer be split