search for: gcref

On Mon, Jul 11, 2016 at 2:28 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > ping! > > Sanjoy Das wrote: > # Proposed Solution: >> >> We introduce a "new" LLVM type. I will still refer to it as GCREF >> here, but it may actually still be "<ty> addrspace(k)*" where k is >> specially noted in the datalayout. >> >> Semantics: >> >> 1. GCREF represents an equivalence class of values (equivalence >> relation being "points to a fi...

...from memory reordering barriers). For more details on GC specific stuff, I suggest referring to http://www.memorymanagement.org/ and our 2014 LLVM-Dev talk http://llvm.org/devmtg/2014-10/#talk4. Getting LLVM ToT working with a precise relocating GC involves taking the following steps: Note: GCREF is the type representing a pointer that the GC needs to know about and potentially relocate. Currently it is `<Ty> addrspace(1)*`. 1. Generate IR, and represent GC pointer SSA values as values of type GCREF. 2. Run opt -O3. 3. Run RewriteStatepointForGC. It rewrites IR v...

...ce" is better, so I'll steal that. :) >> On Jun 24, 2016, at 12:22 AM, Sanjoy Das<sanjoy at playingwithpointers.com> wrote: >> >> Getting LLVM ToT working with a precise relocating GC involves taking >> the following steps: >> >> Note: GCREF is the type representing a pointer that the GC needs >> to know about and potentially relocate. Currently it is `<Ty> >> addrspace(1)*`. >> >> 1. Generate IR, and represent GC pointer SSA values as values of type >> GCREF. >> 2. Run o...

...ose IR optimization or an > ISEL pattern (which should really be somehow denoted and only run in a > later pass). But for the purposes of this discussion, only the legality (or lack thereof) of the above transform matters, not whether it is profitable or not. >> > Converting any GCREF to an integer is BAD, period. A single benign >> use could float below a safepoint. Imagine if you expanded card marks >> early before step #3! >> >> Here I'm trying to constrain the optimizer -- if the frontend wants to >> insert ptrtoints and knows what it i...

Hi Andy, Andrew Trick wrote: >> But for the purposes of this discussion, only the legality (or lack >> thereof) of the above transform matters, not whether it is profitable >> or not. > > Given that you will need to disable the transform for GCRefs, it’s interesting that if it’s only something that needs to run before ISEL then you’re not actually losing any optimization. Ah, okay; that makes sense. >>> If you can come up with an IR design for tracking your GCRef load >>> depedencies (usually on specific null and type...

...implement a more precise version of (2). > > > > [0]: I may have (incorrectly) mentioned otherwise on IRC, but we need > to model safety properties of stores as well, to avoid transforms > like: > > %x = malloc() ;; known thread local > if (cond_0) { > store GCREF %val to %x > } > if (cond_1) { > store i64 %val to %x > } > > to > > %x = malloc() ;; known thread local > if (cond_0 || cond_1) { > store GCREF %val to %x ;; This "speculative" store is bad > if (cond_1) { > store i64 %val...

----- 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 Daniel, Daniel Berlin wrote: > /* Add fake edges to the function exit for any non constant and non > noreturn calls (or noreturn calls with EH/abnormal edges), > volatile inline assembly in the bitmap of blocks specified by > BLOCKS > or to the whole CFG if BLOCKS is zero. > ... > > The goal is to expose cases in

...ee > throughout most of the pass pipeline > - Fundamentally, you don’t really lose anything. It’s an easy > analysis to find the exit points and mark blocks. Doing a CFG walk > instead of a PostDom walk is typically not such a big deal. > The fundamental problem relevant to Precise GCRef is that the > dependence between program conditions and loads can’t be expressed. > I often overload the term “control dependence” here. When I say a > load is control dependent on a branch, I don’t mean that the load’s > block is classically control dependent on the branch, I mean tha...

...re that this is implemented as generically as possible. I'm actually hopeful that the tagging isn't necessary at all. -Chandler > - No pointer <-> integer casts for GC address spaces to begin with > - Add an intrinsic (with control dependence) to > convert GCrefs -> integers (we need this for GC load/store > barriers) > - Disable some of the problematic "cast by round tripping through > memory" type optimizations for loads and stores that are of GC > ref type > > The things above are things we know w...