search for: rhadley

...'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 <rhadley at microsoft.com> wrote: > 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. > > > >...

Hi Lang, I'm looking at extending the compilation passes used in the LLILC JIT and it seems like the simplest thing is to make a copy of the SimpleCompiler functor into the LLILC code and then modify it for the phases I want to run. But I was wondering if this was the best approach. Do you expect different clients to create their own compiler functors or do you imagine that SimpleCompiler

...cs.uiuc.edu] On Behalf Of Vadim Chugunov Sent: Wednesday, April 15, 2015 11:49 AM To: Russell Hadley Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] MS fork Just curious, are you planning to add support for debug info emission in mspdb format? On Wed, Apr 15, 2015 at 7:01 AM, Russell Hadley <rhadley at microsoft.com<mailto:rhadley at microsoft.com>> wrote: Chandler has it right. Our intent is to upstream everything. The MS fork will be used as a staging area for LLVM changes as we work to get them upstreamed. Tactically we're merging the MS fork everyday with mainline to try a...

Hi, I'm trying to do a proof of concept of compiling some code down to a very simple runtime that doesn't provide support for zeroinitialize. If I run the below code through llc: ; ModuleID = '.\t.bc' target datalayout = "e-m:w-p:32:32-i64:64-f80:32-n8:16:32-S32" target triple = "i686-pc-windows-gnu" @_ZN3Foo11ZeroAndZeroE = global [2 x i32] [i32 0, i32 0],

(background) The CoreCLR expects a JIT to produce a MSIL bytecode offset to code offset mapping annotated with a few extra bits denoting if it’s prolog/epilog, or it’s a call, or if there’s operands remaining on the MSIL virtual stack in some cases. Our initial prototype has the MSIL offset stashed in the line number field. We could stash the extra bits in the column info but that’s starting to

Chandler has it right. Our intent is to upstream everything. The MS fork will be used as a staging area for LLVM changes as we work to get them upstreamed. Tactically we're merging the MS fork everyday with mainline to try and stay close. We're still ramping up right now, and trying to figure out how best to work day to day, but our over arching goal is to enable (mainline) LLVM to be

...ugust 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> Subject: Re: RFC: alloca -- specify address space for allocation >>Managed language clients typically use address space 1 to represent GC-pointers. > This is not an entirely accurate statement.  There are currently one in tree GC strategy which uses addrspace(1) for...

...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 microsoft.com>; Andy Ayers <andya at microsoft.com>; Russell Hadley <rhadley at microsoft.com> Subject: Re: RFC: alloca -- specify address space for allocation For the record, at least two other implementation strategies to address the original problem have been discussed. Option 1 (Rejected) - Explode the stack based object into individual fields individual fields bef...

...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> > Subject: Re: RFC: alloca -- specify address space for allocation > >> I think for the use case you are outlining, an addrspacecast is the correct IR model -- >> you're specifically saying that it is OK in this case to turn a pointer from addrspace 0...

...t 29, 2015 12:30 AM > To: Philip Reames <listmail at philipreames.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> > Subject: RE: RFC: alloca -- specify address space for allocation > >> -----Original Message----- >> From: Philip Reames [mailto:listmail at philipreames.com] >> Sent: Friday, August 28, 2015 9:38 AM >> To: Swaroop Sridhar <Swaroop.Sridhar at...

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

...com> Cc: Hal Finkel <hfinkel at anl.gov>; David Majnemer <david.majnemer at gmail.com>; llvm-dev <llvm-dev at lists.llvm.org>; Chandler Carruth <chandlerc at gmail.com>; Nick Lewycky <nlewycky at google.com>; 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> Subject: Re: RF...

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

Specifically, I wanted to sit down with Sanjoy and Philip who have been working on getting the current statepoint infrastructure sufficiently well integrated with the optimizer to do early statepoint insertion, and discuss what the path forward is here. If anyone happens to be in the area and is interested in attending, please let me know. Currently, I'm planning to host things up on

...listmail at philipreames.com>, "Chandler Carruth" > <chandlerc at gmail.com>, "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.c...

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

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

We'd like to propose a scheme to attach "operand bundles" to call and invoke instructions. This is based on the offline discussion mentioned in http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-July/088748.html. # Motivation & Definition Our motivation behind this is to track the state required for deoptimization (described briefly later) through the LLVM pipeline as a

Hey Joseph, What Lang said made me wonder. Is it the right time for us (LLILC) to move to ORC? The long term plan was to go there but this could be our forcing function. -R From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Lang Hames Sent: Friday, May 29, 2015 2:23 PM To: Joseph Tremoulet Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] MCJit interface