Displaying 20 results from an estimated 1000 matches similar to: "[LLVMdev] A few folks in the SF Bay area are planning to get together to discuss GC statepoints"
2015 Jul 30
0
[LLVMdev] A few folks in the SF Bay area are planning to get together to discuss GC statepoints
Hi Chandler,
A few of us up here in Seattle would be interested, but we’re too cheap to buy plane tickets. Is it reasonable to set up a conference call? How the optimizer deals with statepoints is important to us.
-R
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chandler Carruth
Sent: Tuesday, July 28, 2015 8:21 PM
To: Sanjoy Das <sanjoy at
2015 Jul 30
1
[LLVMdev] A few folks in the SF Bay area are planning to get together to discuss GC statepoints
That might work. I'm actually particularly interested in your perspective
here, so even if it doesn't, I had already planned to specifically email
you to make sure I got your thoughts here.
But maybe a conference call would work. By far the easiest is for us to do
a Google hangout, which would give video and audio. Would that work on your
end?
On Thu, Jul 30, 2015, 08:50 Russell Hadley
2015 Jun 17
3
[LLVMdev] design question on inlining through statepoints and patchpoints
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
2015 Jun 17
2
[LLVMdev] design question on inlining through statepoints and patchpoints
The long term plan is a) evolving, and b) dependent on the specific use
case. :)
It would definitely be nice if we could support both early and late
safepoint insertion. I see no reason that LLVM as a project should pick
one or the other since the infrastructure required is largely
overlapping. (Obviously, I'm going to be mostly working on the parts
that I need, but others are always
2016 Mar 03
2
Status of Garbage Collection with Statepoints in LLVM
Hello LLVM community,
We have been experimenting with using LLVM IR as a target for a managed
(dynamically typed) language via an AOT compiler (including a backend for
ARM). One main challenge is getting the garbage collection right: We would
like to be able to implement a moving collector. This requires us to a)
find a precise set of root pointers and b) be able to rewrite those
pointers after
2016 Mar 04
2
Status of Garbage Collection with Statepoints in LLVM
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
2015 May 25
2
[LLVMdev] GC Statepoint Transition Status?
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
2015 Dec 31
2
[GC / Statepoints] Collector supports only base pointers as stack roots
Hi,
My collector supports only base pointers as stack roots. This wasn't a
problem until I tried to run some optimizations before RS4GC, which
introduced (interior) derived pointers. The statepoint documentation
mentions that these collectors exist, but doesn't mention whether and
how this is currently supported. What could I do to make it work?
-Manuel
2015 Nov 13
2
llvm.experimental.gc.statepoint genarates wrong Stack Map (or does it?)
Hello, list
I am not quite sure if what I'm experiencing is a bug or intentional
behavior.
In the code below the result of a function call is a deopt arg to
llvm.experimental.gc.statepoint
(http://llvm.org/docs/Statepoints.html#llvm-experimental-gc-statepoint-intrinsic).
Therefore a Stack Map containing location of this variable is created
upon code generation.
Here's the complete
2016 Jan 27
3
PlaceSafepoints, operand bundles, and RewriteStatepointsForGC
[+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
2014 Dec 05
9
[LLVMdev] Future plans for GC in LLVM
Now that the statepoint changes have landed, I wanted to start a
discussion about what's next for GC support in LLVM. I'm going to
sketch out a strawman proposal, but I'm not set on any of this. I
mostly just want to draw interested parties out of the woodwork. :)
Overall Direction:
In the short term, my intent is to preserve the functionality of the
existing code, but migrate
2017 Dec 08
4
Non-relocating GC with liveness tracking
Hi Team,
I'm working on a new pure functional language and I'm trying to add GC
support for that.
Because all vars are immutable, the IR that my frontend generates are all
register based, i.e. no alloca, and no readmem, writemem unless
accessing/constructing structs.
If I use the traditional GC with gcroot intrinsic, it will need to emit
more code for liveness tracking, storing the IR
2018 Nov 19
2
Non-relocating GC with liveness tracking
Thanks for reviving this.
I completely forgot the details but I resolved this problem. Looking though
the code, seems I forked RewriteStatepointsForGC pass, and change it to
adding 'gc-livevars' bundle to the call/invoke inst after finding the
livevars, instead of changing it to StatepointCall intrinsic.
On Wed, Nov 14, 2018 at 11:48 AM Philip Reames <listmail at philipreames.com>
2019 Jul 26
2
Stackmap offset computation on AArch64
Hi all,
I am trying to implement statepoints for the AArch64 target and I’m running into the issue where the following bitcode:
define i32 addrspace(1)* @test(i32 addrspace(1)* %ptr) gc "statepoint-example" {
entry:
call token (i64, i32, i1 ()*, i32, i32, ...) @llvm.experimental.gc.statepoint.p0f_i1f(i64 0, i32 0, i1 ()* @foo, i32 0, i32 0, i32 0, i32 0, i32 addrspace(1)* %ptr)
ret
2018 Nov 01
2
Building GC on statepoint-example
Hi,
I'm trying to build a gc using the statepoint-example strategy. However, after hours of searching, reading documentation and trying to find code examples online, I cannot figure out how to access the Stack Map.
The documentation for statepoint-example says:
The stack map format generated by this GC strategy can be found in the Stack Map
2015 Nov 16
2
llvm.experimental.gc.statepoint genarates wrong Stack Map (or does it?)
> Vlad,
>
> My initial impression is that you've stumbled across a bug. I suspect
> that we - the only active users of the deopt info in the statepoint I
> know of - have been inverting the meaning of Direct and Indirect
> throughout our code. (i.e. we're consistent, but swapped on the
> documented meaning) I've asked Sanjoy to confirm that, and if he
>
2018 Jan 13
3
How to use stack maps
Is there an explanation anywhere of what code that uses a stack map looks
like? I'm interested in writing a garbage collector, but it's not clear to
me how my code should make use of the stack map format to actually locate
roots in memory.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
2015 Jan 19
2
[LLVMdev] [INCOMPLETE] [GC] Support wrapping vararg functions in statepoint
I actually need this feature quite badly in my untyped language
compiler: since I support first-class functions, I've made the types of
all functions a standard vararg (so I can box them).
The implementation crashes when I try to read out the value of
gc.result. Hints as to what might be wrong?
Signed-off-by: Ramkumar Ramachandra <artagnon at gmail.com>
---
2018 Jan 14
0
How to use stack maps
Hi,
I implemented a garbage collector for a language I wrote in college using
the llvm gc statepoint infrastructure.
Information for statepoints:
https://llvm.org/docs/Statepoints.html
Example usage of parsing the llvm stackmap can be found at:
https://github.com/dotnet/llilc/blob/master/lib/GcInfo/GcInfo.cpp
https://llvm.org/docs/StackMaps.html#stackmap-format
2015 Jan 20
3
[LLVMdev] [INCOMPLETE] [GC] Support wrapping vararg functions in statepoint
Philip Reames wrote:
> Any change outside of statepoint lowering is highly suspect.
Notice that SelectionDAGBuilder::LowerCallTo (the one I'm modifying)
has exactly one other caller: visitCall, which doesn't match vararg
functions. Every other codepath directly calls
TargetLowering::LowerCallTo, supplying CallLoweringInfo information
explicity (it's a structure with a vararg