similar to: 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

> On Jul 9, 2015, at 3:33 PM, Swaroop Sridhar <Swaroop.Sridhar at microsoft.com> wrote: > > Regarding Call-site size specification: > > CoreCLR (https://github.com/dotnet/coreclr <https://github.com/dotnet/coreclr>) requires the size of the Call-instruction to be reported in the GCInfo encoding. > > The runtime performs querries for StackMap records using

Hi All, TLDR: Allow calling conventions to be defined on-the-fly for functions in LLVM-IR, comments are requested on the mechanism and syntax. Summary ======= This is a proposal for adding a mechanism by which LLVM can be used to generate code fragments adhering to an arbitrary calling convention. Intended use cases are: generating code intended to be called from the shadow of a stackmap or

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

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

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

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. Previously, the RS4GC pass was attempting to

Hi @ll, over the past year we gained more experience with the patchpoint/stackmap/statepoint intrinsics and it exposed limitations in the stackmap format. The following proposal includes feedback and request from several interested parties and I would like to hear your feedback. Missing correlation between functions and stackmap records: Originally the client had to keep track of the ID to know

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

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

Hi all, I would like to propose a mechanism that would allow LLVM to fold null pointer checks into "nearby" memory operations, subject to runtime support. This is related to but not exactly the same as a proposal floated by Peter Collingbourne earlier [1]. The obvious use cases are managed languages like Java, C# and Go that require a null check on pointers before they're used in

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

> On Oct 31, 2014, at 5:28 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Hi Kevin, > > Thank you for starting this discussion! Yes, sorry for being unresponsive for a few days. Sanjoy summarized the issues perfectly. > I think the distinction is really between whether the live values are > "live on call" or "live on return".

Hi, Sanjoy, On 2015-11-16 23:27, Sanjoy Das wrote: > Hi Vlad, > > vlad via llvm-dev wrote: >>> 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 >>>

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>

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

On Oct 22, 2013, at 1:48 PM, Philip R <listmail at philipreames.com> wrote: > On 10/22/13 10:34 AM, Filip Pizlo wrote: >> On Oct 22, 2013, at 9:53 AM, Philip R <listmail at philipreames.com> wrote: >> >>> On 10/17/13 10:39 PM, Andrew Trick wrote: >>>> This is a proposal for adding Stackmaps and Patchpoints to LLVM. The >>>> first client

I think what's happening is BranchFolder::MaintainLiveIns is using a forward analysis on top of these missing kill flags, and updating the BB-live-ins/live-outs with an incorrect set of registers. Then when the stackmaps liveness analysis happens, it's not doing anything wrong, but it starts with the wrong set of live registers and will propagate those to the point of the

Hi all, I've run into a couple bugs recently that affected stackmap liveness analysis in various ways: http://llvm.org/bugs/show_bug.cgi?id=19224 - function arguments stay live unnecessarily http://llvm.org/bugs/show_bug.cgi?id=21265 - eflags can end up as a live out http://llvm.org/bugs/show_bug.cgi?id=21266 - %rip can end up as a live out The first two have nothing to do with stackmaps

On Oct 22, 2013, at 9:53 AM, Philip R <listmail at philipreames.com> wrote: > On 10/17/13 10:39 PM, Andrew Trick wrote: >> This is a proposal for adding Stackmaps and Patchpoints to LLVM. The >> first client of these features is the JavaScript compiler within the >> open source WebKit project. >> > I have a couple of comments on your proposal. None of these