Displaying 7 results from an estimated 7 matches for "gcprinter".
2010 Oct 02
2
[LLVMdev] Function inlining creates uninitialized stack roots
...e these
constraints. For example, say I have a function F:
void F() {
f1();
f2();
}
Let's say that f1() causes a stack crawl (perhaps by triggering a collection
cycle), and that f2() declares a stack root 'a'. If the optimizer decides to
inline f2, then by the time the GCPrinter is called the resulting code looks
like this:
- a = alloca
- call f1
- call llvm.gcroot(a)
- store null, a
The inliner moved the alloca instruction to the top of the function, but not
the call to llvm.gcroot or the initialization of the variable. In other
words, the initialization of...
2010 Oct 02
2
[LLVMdev] Function inlining creates uninitialized stack roots
...void F() {
>> f1();
>> f2();
>> }
>>
>> Let's say that f1() causes a stack crawl (perhaps by triggering a
>> collection cycle), and that f2() declares a stack root 'a'. If the optimizer
>> decides to inline f2, then by the time the GCPrinter is called the resulting
>> code looks like this:
>>
>> - a = alloca
>> - call f1
>> - call llvm.gcroot(a)
>> - store null, a
>>
>> The inliner moved the alloca instruction to the top of the function, but
>> not the call to llvm.gcroo...
2010 Oct 02
0
[LLVMdev] Function inlining creates uninitialized stack roots
...e a function F:
>
> void F() {
> f1();
> f2();
> }
>
> Let's say that f1() causes a stack crawl (perhaps by triggering a
> collection cycle), and that f2() declares a stack root 'a'. If the optimizer
> decides to inline f2, then by the time the GCPrinter is called the resulting
> code looks like this:
>
> - a = alloca
> - call f1
> - call llvm.gcroot(a)
> - store null, a
>
> The inliner moved the alloca instruction to the top of the function, but
> not the call to llvm.gcroot or the initialization of the varia...
2010 Oct 02
0
[LLVMdev] Function inlining creates uninitialized stack roots
...f1();
>>> f2();
>>> }
>>>
>>> Let's say that f1() causes a stack crawl (perhaps by triggering a
>>> collection cycle), and that f2() declares a stack root 'a'. If the optimizer
>>> decides to inline f2, then by the time the GCPrinter is called the resulting
>>> code looks like this:
>>>
>>> - a = alloca
>>> - call f1
>>> - call llvm.gcroot(a)
>>> - store null, a
>>>
>>> The inliner moved the alloca instruction to the top of the function, but
>...
2013 Dec 18
1
[LLVMdev] GCModuleInfo and MCJIT
...he llvm gc infrastructure
can work with the current MCJIT without any change (good news).
I will explain what I have done to find the garbage collector metadata
generated by llvm with MCJIT, I'm pretty sure that it could help
someone.
And it's very easy. You just have to activate a static gcprinter for
the assembly. A very good example is given in
OcamlGCPrinter.cpp/OCamlGC.cpp. The only problem with the hook of
OcamlGCPrinter::finishAssembly() is that it changes the current
section to emit the gc metadata in the data section. And it does not
work with MCJIT. I don't know why, probably be...
2013 Dec 18
0
[LLVMdev] GCModuleInfo and MCJIT
Hi!
I have now a more precise question, I hope that this time, someone
will be able to help me :)
I'm now able to find the gc meta data. To find this data, I simply
register a GCMetadataPrinter (just like during an AOT compilation). A
GCMetadataprinter is called at the end of the compilation of a module
after having assigned the slots to the live roots. I have almost
everything except that
2013 Dec 15
2
[LLVMdev] GCModuleInfo and MCJIT
Hi all,
So, MCJIT is working with vmkit, that's great. However, I need to
retrieve the GCModuleInfo and the MachineCodeEmitter used during the
compilation process. And I don't know how I should proceed? I'm trying
to understand how they are preserved with the old jit, but I have to
say that I'm a little bit lost because I haven't a global view of the
code... So, any help would