search for: rewritestatepointsforgc

----- Original Message ----- > From: "Andrew Trick" <atrick at apple.com> > To: "Sanjoy Das" <sanjoy at playingwithpointers.com> > Cc: "Daniel Berlin" <dberlin at dberlin.org>, "llvm-dev" <llvm-dev at lists.llvm.org>, "Joseph Tremoulet" > <jotrem at microsoft.com>, "Oscar Blumberg"

[+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

...wondering what’s the community guideline for adding new passes which are solely used for debugging/analysis purposes? Can this be in the upstream llvm, or such passes are more suitable in local downstream repository? In our case, the ‘utility (ease-of-analysis)’ pass is for transformation done by RewriteStatepointsForGC (RS4GC). Note that right now, RS4GC is not enabled in the opt pipeline upstream, but the utility pass would be for downstream users who have RS4GC enabled in their opt pipeline. Thanks, Anna

...wondering what’s the community guideline for adding new passes which are solely used for debugging/analysis purposes? Can this be in the upstream llvm, or such passes are more suitable in local downstream repository? In our case, the ‘utility (ease-of-analysis)’ pass is for transformation done by RewriteStatepointsForGC (RS4GC). Note that right now, RS4GC is not enabled in the opt pipeline upstream, but the utility pass would be for downstream users who have RS4GC enabled in their opt pipeline. I think you should start by describing exactly what the pass is doing and how it is useful for working with/on RewriteSt...

...ere exists some GC-strategy that uses address-space annotation to differentiate gc-pointers from native-pointers. > I'm not directly opposed to this proposal, but I'm not really in support of it either.  > I think there a number of smaller engineering changes which could be made to RewriteStatepointsForGC to address this issue.  > I am not convinced we need to allow addrspace on allocas to solve that problem. > More generally, I'm a bit bothered by how your asserting that a pointer to a stack based object is the same as a managed pointer into the heap.  > They share some properties -...

...low construction of GC pointers to stack locations. For example, MSIL instruction ldloca (ECMA 335, p 370) creates a GC pointer to a stack local. Creating an addrespace(1)* pointer to a stack location currently involves two steps: the alloca, and an addrspacecast. Managed code transformations (ex: RewriteStatepointsForGC) do not handle arbitrary address space casting. So, it is desirable to obtain the addrespace(1)* pointer by construction. Thanks, Swaroop. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150827/9debdc4c/atta...

...d stores that are of GC > ref type > > The things above are things we know we need, and even if all we do is > implement those, we will be in a better position overall. > > > One thing I want a design opinion on (already discussed on IRC): I'm > planning to phrase RewriteStatepointsForGC (a ModulePass) that > "implements" GC references "in terms of" normal pointers. One way to > do this is to rewrite each def and user of GC refs to use a normal > pointer, but that's unnecessary data structure churn, so I was > wondering if instead we can flip th...

...the safepoint can introduce writes which didn't exist in the original program. Option 2 - Consider pointers within stack based objects (allocas in addrspace 0) as being live and add their addresses (not values) to the stackmap.  This could be done by extending the liveness analysis already in RewriteStatepointsForGC to consider allocas containing pointers.  There wouldn't be any addrspace casts involved since the members of the stack based object are addrspace(1) pointers to start with.  Loading them produces an SSA value which can be relocated as usual.  I don't remember hearing a clearly expressed re...

...Now I am implementing the safepoint functionality which is why I use >> the >> gc.statepoint intrinsic. The two utility passes have been extremely >> helpful. The use-cases they support are much more general than my >> needs >> though. So I use a modified version of RewriteStatepointsForGC, which >> only appends the pointer values live across the statepoint to <deopt >> args>. > > If I understand you correctly, that will work only if your GC isn't a > relocating GC. Is that the case? V8's GC is a relocating GC. When it moves an object which is l...

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 looked at online (statepoint-ut...

...39;d like to record the locations of *all* > live values whenever I insert the intrinsic (all this entails is What is your definition of a live value? Some more context on what you intend to do with stackmaps will be helpful too. LLVM has a restricted form of a live value analysis that in the RewriteStatepointsForGC pass, and its intended use is to rewrite LLVM IR in a way that it can work with a precise compacting garbage collector; but it looks like you want something more general? > adding values as arguments to the intrinsic). Is there any > pre-existing analysis pass which can give me the live val...

TLDR. For anyone who is using the RewriteStatepointsForGC utility pass, there is a recent change you should know about which may require you to make some small changes to your stackmap parsing. I have landed a small series of patches which change how we're handling vector of pointers when reporting live pointers for the GC at safepoints. Previou...

...e 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 looked at online (statepoint-ut...

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 ve...

...m.org/docs/Statepoints.html [placesafepoints] https://github.com/llvm-mirror/llvm/blob/a40ba754c3f765768d441b9b4b534da917f8ad3c/lib/Transforms/Scalar/PlaceSafepoints.cpp#L441 [rewritestatepoints] https://github.com/llvm-mirror/llvm/blob/a40ba754c3f765768d441b9b4b534da917f8ad3c/lib/Transforms/Scalar/RewriteStatepointsForGC.cpp#L2286 [backend-x64] https://github.com/llvm-mirror/llvm/blob/a40ba754c3f765768d441b9b4b534da917f8ad3c/lib/Target/X86/X86MCInstLower.cpp#L841 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160303/818cb257...

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> wrote: > Returning to an ancient thread. Sorry...

Hi everyone, I'm writing a pass that inserts the llvm.experimental.stackmap intrinsic into the IR, and I'd like to record the locations of *all* live values whenever I insert the intrinsic (all this entails is adding values as arguments to the intrinsic). Is there any pre-existing analysis pass which can give me the live values at a given instruction in a basic block? Or do I need to

...ach type of Location except Direct so far). Now I am implementing the safepoint functionality which is why I use the gc.statepoint intrinsic. The two utility passes have been extremely helpful. The use-cases they support are much more general than my needs though. So I use a modified version of RewriteStatepointsForGC, which only appends the pointer values live across the statepoint to <deopt args>. > Philip > > On 11/13/2015 03:17 AM, vlad via llvm-dev wrote: >> Hello, list >> >> I am not quite sure if what I'm experiencing is a bug or intentional >> behavior. &g...

...other you, but I would like to get some suggestions on your recent work of token type. I’m currently working on changing gc.statepoint to return a token type instead of a i32 type. The reason is that with the current implementation, gc.statepoint could potentially be fed into PHI nodes, and break RewriteStatepointsForGC pass later. Using token type would help us to avoid this. I have most of the code work but got a problem when gc.statepint is an InvokeInst and has an unwind path. Currently, gc.statepoint of InvokeInst works as below (the code snippet is from test/CodeGen/X86/statepoint-invoke.ll): %0 = invoke...

...atomic calls "requires-statepoint". This attribute on a call will result in a different lowering, which makes it possible to have a GC safepoint during the copy operation. There are three parts to the new lowering: 1) The calls with the new attribute will be wrapped into a statepoint by RewriteStatepointsForGC (RS4GC). This way the stack at the calls will be GC parceable. 2) Currently these intrinsics are lowered to GC leaf calls to the symbols __llvm_{memcpy|memmove}_element_unordered_atomic_<element_size>. The calls with the new attribute will be lowered to calls to different symbols, let's...