search for: gcrefs

...cref.store_gcref(GCREF*, GCREF*, offset, value) which load and store a gcref through a gcref. 4. Add intrinsics gcref.load_value(GCREF*, offset) and gcref.store_value(GCREF*, offset, value) which load and store normal values a gcref. 5. The statepoint lowering pass gets rid of the allocas. Keeping GCREFs exclusively in memory means the LLVM optimizer will handle them conservatively, but correctly. I guess the problem with this is precisely that the LLVM optimizer will handle them conservatively... but on the flip side, I think you're going to end up chasing down weird problems forever if a &qu...

...ns or any other potentially trapping operation, but I think a lot of LLVM directly encodes the fact that `CastInst` s are obviously speculatable, so maybe Integer -> GCREF casts should be outlawed at the type system level, and be done via an intrinsic? ### Store forwarding between integers and GCREFs is valid store i64 %val, i64* %loc %val = load GCREF, GCREF* (bitcast %loc) ==> store i64 %val, i64* %loc %val = inttoptr %val to GCREF is valid. Both the initial and the final program assume that %val is a valid bitwise representation of a GC reference. (Note: it may not be valid to specula...

...he point of conversion. This is really intended to support "object pinning", where the frontend converts a GC reference to an integer and uses it as such. The key phrase above is "colluding with the GC" -- you need whitebox knowledge of how the GC works to be able to do convert GCREFs to integers reliably. > >> 4. Converting integers to GCREF is allowed only if source integer is >> a bitwise representation of a valid GC reference that is not an >> out of bounds derived reference. However, this is difficult for >> the compiler to infe...

...y "simple invariants don’t hold", but in the >> example above "void f(A a) {", putting junk on the else path does not >> help. > > For that to work, you would have to know where potential statepoints > might be, which is why it breaks the invariant that GCRefs are always > valid, and why I proposed only doing this within the safepoint insertion > pass. > >> > This is optimization is probably best done contained in step #3, >> rewriting. >> >> I don't think that's a good idea -- we'll have to replicat...

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

On Thu, Jul 14, 2016 at 4:48 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi all, > > It looks like the key controversial point is the bit about the extra > control dependence on loads and stores[0]. Generally the consensus is > that (please chime if you think otherwise) it is not reasonable to > make the safety (or semantics) of a load instruction depend

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

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

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