Displaying 3 results from an estimated 3 matches for "ircompilinglay".
Did you mean:
ircompilinglayer
2015 Mar 14
2
[LLVMdev] Thoughts about ExecutionEngine/MCJIT interface
Another question: Lang, when do you think it'll be ok to move it to the C
Bindings?
On Fri, Mar 13, 2015 at 6:39 PM, Lang Hames <lhames at gmail.com> wrote:
> Hi Pawel,
>
> I agree. ExecutionEngine, in its current form, is unhelpful. I'd be in
> favor of cutting the common interface back to something like:
>
> class ExecutionEngine {
> public:
> virtual
2015 Jan 14
4
[LLVMdev] New JIT APIs
...he
layers that are currently included in the patch are the the
CompileOnDemandLayer, which breaks up modules and redirects calls to
not-yet-compiled functions back into the JIT; the LazyEmitLayer, which
defers adding modules to the layer below until a symbol in the module is
actually requested; the IRCompilingLayer, which compiles bitcode to
objects; and the ObjectLinkingLayer, which links sets of objects in memory
using RuntimeDyld.
Utilities are everything that's not a layer. Ideally the heavy lifting is
done by the utilities. Layers just wrap certain uses-cases to make them
easy to compose.
Clients...
2015 Jan 16
5
[LLVMdev] New JIT APIs
...urrently included in the patch are the the
> CompileOnDemandLayer, which breaks up modules and redirects calls to
> not-yet-compiled functions back into the JIT; the LazyEmitLayer, which
> defers adding modules to the layer below until a symbol in the module is
> actually requested; the IRCompilingLayer, which compiles bitcode to
> objects; and the ObjectLinkingLayer, which links sets of objects in memory
> using RuntimeDyld.
>
> Utilities are everything that's not a layer. Ideally the heavy lifting
> is done by the utilities. Layers just wrap certain uses-cases to make them...