similar to: Adding utility/debugging passes upstream

Hi Mehdi, On Sep 30, 2016, at 4:27 PM, Mehdi Amini <mehdi.amini at apple.com<mailto:mehdi.amini at apple.com>> wrote: On Sep 30, 2016, at 12:37 PM, Anna Thomas via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hi, I was wondering what’s the community guideline for adding new passes which are solely used for debugging/analysis purposes?

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

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

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

TLDR: a proposal to add GC-parseable lowering to element atomic memcpy/memmove instrinsics controlled by a new "requires-statepoint” call attribute. Currently llvm.{memcpy|memmove}.element.unordered.atomic calls are considered as GC leaf functions (like most other intrinsics). As a result GC cannot occur while copy operation is in progress. This might have negative effect on GC latencies

Thanks for the feedback. I think both of the suggestions are very reasonable. I’ll incorporate them. Given there were no objections for two weeks, I’m going to go ahead with posting individual patches for review. One small question inline: On Sep 28, 2020, at 10:56 AM, Philip Reames <listmail at philipreames.com<mailto:listmail at philipreames.com>> wrote: In general, I am

Sorry to reply to myself here, but I had an idea regarding "issue #2" -- possibly what makes the most sense for those clients/targets is to pull the pointer difference computation/reapplication into RS4GC itself -- it could have a pass just before or after rematerialization, which runs based on a configuration flag (eventually to be driven by GCStrategy), which performs rewrites like

Thanks, I think that's a useful way to look at it (though if I wanted to bikeshed I'd suggest the name "DoubleIndirect" as a bit more precise than "VeryIndirect"). An aspect of it that I'm still puzzling over is that my target runtime (at least in its current form) doesn't have a way to represent/process a "VeryIndirect" pointer. So I'd like to

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

For anyone following along on ToT using the gc.statepoint mechanism, you should know that ToT is currently not able to express arbitrary exceptional control flow and relocations along exceptional edges. This is a direct result of moving the gc.statepoint representation to using a token type landingpad. Essentially, we have a design inconsistency where we expect to be able to

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

Inline. From: Philip Reames [mailto:listmail at philipreames.com] Sent: Thursday, August 27, 2015 11:01 AM To: Swaroop Sridhar <Swaroop.Sridhar at microsoft.com>; llvm-dev <llvm-dev at lists.llvm.org>; Sanjoy Das <sanjoy at playingwithpointers.com> Cc: Joseph Tremoulet <jotrem at microsoft.com>; Andy Ayers <andya at microsoft.com>; Russell Hadley <rhadley at

Philip: I think there are two separate issues: 1) Handling GC pointers stored in stack locations -- tracking their liveness, reporting them to the GC. etc. 2) Treating pointers to stack locations as GC-pointers. I think the two options that you presented here are for solving (1). I'm trying to solve issue (2) using alloca in addrspace(1). Basically, we want to create a pointer to a stack

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

Currently, the alloca instruction always allocates in the generic address space (0). This proposal is to extend the semantics of alloca instruction to allow allocation in any specified address space. Proposed Syntax <result> = alloca [inalloca] <type> [, <ty> <NumElements>] [, align <alignment>] [, addrspace <num>] ; yields type addrspace(num)*:result

Hi Rob, On Thu, Mar 24, 2016 at 12:35 PM, Rob Lyerly via llvm-dev <llvm-dev at lists.llvm.org> wrote: > 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 What is your definition of a live value? Some more

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

----- 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"

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

Hello All, We would like to call quantile() function from the R-package STATS in a Delphi program. If this is possible, could anyone provide us with an example? Thanks in advance. --Anna ----------------------------------------- Anna Belova Abt Associates Inc. 4800 Montgomery Ln, St 600 Bethesda, MD-20814 phone: 301-347-5304 fax: 301-652-7530 http://www.abtassociates.com/environment