search for: placesafepoints

[+CC llvm-dev this time] Hi, As discussed in the review thread in http://reviews.llvm.org/D16439, the future plan around statepoints, deopt bundles, PlaceSafepoints etc. is to "constant fold" -spp-no-statepoints and -rs4gc-use-deopt-bundles to true. We (Azul) have moved to a representation of safepoint polls, deopt state etc. that enables us to do the above; and at this point I'm waiting for an okay from you guys. LLILC should mostly Just Work...

...t option, namely "gcroot", is only viable for conservative collectors and statepoints might eventually replace gcroot. So we wanted to try out the statepoints approach. Though it turned out that: * the pass for inserting statepoints is hard-coded to only work with samples and CLR (see [placesafepoints]) * the pass for rewriting statepoints is hard-coded to only work with samples and CLR (see [rewritestatepoints]) * the only backend supporting statepoints right now seems to be 64-bit intel (see [backend-x64]) Since the ARM backend (and e.g. 32-bit intel) doesn't seem to have support for...

Hi Martin, Philip covered all of it very well, I'll just add one minor comment: > More generally, can I back up and ask an important question? Do you have to > support deoptimization (i.e. osr side exits) in any form? If you do, you'll > probably want to avoid the PlaceSafepoints utility pass. If you need to PlaceSafepoints is inadequate only if you have asynchronous invalidation -- i.e. thread X is spinning in a long running loop while thread Y loaded a class that makes the code running in thread X invalid, so thread X needs to be polling for deopt safepoints. If all yo...

Hi, I'm trying to use the statepoint-example strategy to build a simple garbage collector. After using the PlaceSafepoints and RewriteStatepointsForGC passes, I can successfully generate a stack map in my binary and call into my runtime's gc poll. As far as I can tell, I need the stack pointer at the point of the poll to find the correct frame in the stack map. I'm having trouble doing that. One library I loo...

...n your generated code and your C/C++ runtime code which grabs the PC from the stack, and moves it into an argument register. Philip On 11/7/18 5:22 PM, Jordan Rudd via llvm-dev wrote: Hi, I'm trying to use the statepoint-example strategy to build a simple garbage collector. After using the PlaceSafepoints and RewriteStatepointsForGC passes, I can successfully generate a stack map in my binary and call into my runtime's gc poll. As far as I can tell, I need the stack pointer at the point of the poll to find the correct frame in the stack map. I'm having trouble doing that. One library I loo...

As part of adding `"deopt"` operand bundles, we're aiming to change RewriteStatepointsForGC (called RS4GC henceforth) from rewriting existing `gc.statepoint` calls to transforming normal LLVM calls and invokes into `gc.statepoint` calls and invokes (i.e. to do PlaceSafepoints + RS4GC in one step). This will make `gc.statepoint` an artifact of the gc lowering strategy that only appears very late in the pipeline, and not a generic "meta call". For us, this opens up the possibility of making the optimizer work well around calls with deopt state (e.g. be able to...

...39;s likely that we'll end with a scheme which inserts safepoint polls quite early (but with restricted semantics and optimization impact) and then converts them to explicit GC safepoints (with full invalidation semantics) quite late. We already have this distinction in tree in the form of PlaceSafepoints and RewriteStatepointsForGC. I suspect we'll move further in this direction. I suspect that for languages without deoptimization, you'll want to insert safepoint polls quite late. Whether you do the same for safepoints-at-calls is debatable. I used to think that you should do that...

Hi, I am looking to utilize LLVM as the backend in an existing compiler for a garbage collected language, and have a question regarding the current and future support for precise GC in LLVM. It appears that gc.root is being phased out, with with breaking changes such as this: http://reviews.llvm.org/D7004 <http://reviews.llvm.org/D7004> Does this mean that gc.statepoint is ready for

Hello, I've spent some time with the LLVM documentation and am beginning to grasp a few things, but I sometimes need very literal statements to actually understand things. My first question is about StackMaps: Is it true that llvm_gc_root_chain is an API? I've been trying to understand how exactly one accesses this structure and no where in the documentation does it mention this is a

I've been looking at inlining invokes / calls done through statepoints and I want to have a design discussion before I sink too much time into something I'll have to throw away. I'm not actively working on adding inlining support to patchpoints, but I suspect these issues are applicable towards teaching LLVM to inline through patchpoints as well. There are two distinct problems to

...build llvm[3]: Compiling OcamlGCPrinter.cpp for Release+Asserts build llvm[3]: Compiling InstCombineShifts.cpp for Release+Asserts build llvm[3]: Compiling PartiallyInlineLibCalls.cpp for Release+Asserts build llvm[3]: Compiling WinCodeViewLineTables.cpp for Release+Asserts build llvm[3]: Compiling PlaceSafepoints.cpp for Release+Asserts build llvm[3]: Compiling InstCombineSimplifyDemanded.cpp for Release+Asserts build llvm[3]: Compiling WinException.cpp for Release+Asserts build llvm[4]: Building Release+Asserts Archive Library libLLVMX86AsmParser.a make[4]: Leaving directory '/home/NIKHILREDDY/WORK/LLV...