search for: swaroop

...done in one instruction if the alloca can specify the addrspace of the pointer created. The advantage of doing this in one step is, for example, that we can check that there are no (other) addrspace(0) -> addrspace(1) casts. (introduced inadvertently by user code or compiler transformations). Swaroop. From: Philip Reames [mailto:listmail at philipreames.com] Sent: Thursday, August 27, 2015 1:47 PM 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 m...

...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/attachment-0001.html>

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

Please see inline. From: Chandler Carruth [mailto:chandlerc at google.com] Sent: Wednesday, August 26, 2015 7:03 PM To: Swaroop Sridhar <Swaroop.Sridhar at microsoft.com>; llvm-dev <llvm-dev at lists.llvm.org>; Philip Reames <listmail at philipreames.com>; Sanjoy Das <sanjoy at playingwithpointers.com> Subject: Re: [llvm-dev] RFC: alloca -- specify address space for allocation On Wed, Aug 26, 2015 a...

On 08/26/2015 07:02 PM, Chandler Carruth wrote: > On Wed, Aug 26, 2015 at 6:46 PM Swaroop Sridhar via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Currently, the alloca instruction always allocates in the generic > address space (0). > > This proposal is to extend the semantics of alloca instruction to...

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 microsoft.com> Subjec...

> -----Original Message----- > From: Philip Reames [mailto:listmail at philipreames.com] > Sent: Friday, August 28, 2015 9:38 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 microsof...

...uages 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 quite late, but I'm no longer sure that's always the right answer. Philip On 06/17/2015 04:13 PM, Swaroop Sridhar wrote: > With respect to phase ordering, is the long term plan to run the statepoint placement/transformation phases late (after all optimizations)? > If so, will we need to support inlining post statepoint transformation? > > Thanks, > Swaroop. > > -----Original Messag...

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

...there is only one) is outside-the-GC-heap, the question is one of whether you want to conceptualize an alloca as producing an unmanaged address or as producing a pointer into the outside-the-GC-heap pseudo-object. I'd argue that our source language conceptualizes it as the latter[1], which (as Swaroop points out below) is why it would feel natural to model it that way in LLVM, but of course (as Swaroop also points out below) we could also decompose the source construct into two steps in LLVM IR. As far as compiler-introduced allocas, they of course wouldn't be referenced in the source, and...

...elongs to which function, but this would stop working once functions are inlined. The new format fixes that by adding a direct reference from the function to the stackmap records. Call Size and Function Size: These are additional information that are of interest and have been added to the format. @Swaroop: Could you please provide a little more detailed explanation on the "Call Size" field and what exactly is there recorded. Is it just the call instruction or also the materialization code for the address? For what is this used for? Flat format: We think moving to a flat form will make par...

...there are more than one pid's nested within sid. If there is only pid for a sid, like for 2.1 below, I want R to write a 0. In the data below, I want to get the mean of slopes for pid (1.1; 4.1; and 5.1) because they are nested within sid 1.1 and so on. Thanks in advance for any suggestions. Swaroop sid pid slope 1.1 1.1 2 1.1 4.1 3 1.1 5.1 2 2.1 5.1 3 3.2 1.2 2 3.2 1.7 3 [[alternative HTML version deleted]]

On 27 Aug 2015, at 07:40, Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Wed, Aug 26, 2015 at 8:25 PM Matt Arsenault <Matthew.Arsenault at amd.com> wrote: > On 08/26/2015 07:02 PM, Chandler Carruth via llvm-dev wrote: >> >> Without a better understanding of both the motivation and the resulting consequences such as what I've outlined

A high level summary of the proposal as it stands right now (from my perspective), after incorporating Philip's suggestions: 1. Operand bundles are a way to associate a set of SSA values with a call or invoke. 2. Operand bundles are lowered in some arbitrary bundle-tag specific manner. 3. The optimizer can optimize around operand bundles with (roughly) the assumption that

Looks good to me too. Thanks. Swaroop. -----Original Message----- From: Philip Reames [mailto:listmail at philipreames.com] Sent: Wednesday, August 19, 2015 6:55 PM To: Sanjoy Das <sanjoy at playingwithpointers.com> Cc: Hal Finkel <hfinkel at anl.gov>; David Majnemer <david.majnemer at gmail.com>; llvm-dev <llvm-...

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

...RR, 'Could not find the domain. ERROR: %s.' % (e)) sys.stdout = sys.__stdout__ sys.stderr = sys.__stderr__ Output: $ python test.py libvirt: QEMU Driver error : Domain not found: no domain with matching name 'abcd' $ Is there a way to avoid this console print? Regards, Swaroop

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

..."Nick Lewycky" <nlewycky at google.com>, "Hal > Finkel" <hfinkel at anl.gov>, "Chen Li" <meloli87 at gmail.com>, "Russell > Hadley" <rhadley at microsoft.com>, "Kevin Modzelewski" > <kmod at dropbox.com>, "Swaroop Sridhar" > <Swaroop.Sridhar at microsoft.com>, rudi at dropbox.com, "Pat Gavlin" > <pagavlin at microsoft.com>, "Joseph Tremoulet" <jotrem at microsoft.com>, > "Reid Kleckner" <rnk at google.com> > Sent: Monday, August 10, 2015...

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