similar to: RFC: Strong GC References in LLVM

On Thu, Jul 14, 2016 at 4:48 PM Sanjoy Das via llvm-dev < llvm-dev at lists.llvm.org> 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

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

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

On Fri, Jul 15, 2016 at 12:21 PM, Sanjoy Das <sanjoy at playingwithpointers.com > wrote: > Hi Daniel, > > Daniel Berlin wrote: > > As a starting point, LLVM will conservatively not speculate such > > loads and stores; and will leave open the potential to upstream > > logic that will have a more precise sense of when these loads > and

On Fri, Jul 15, 2016 at 2:30 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi Daniel, > > Daniel Berlin wrote: > > However, I didn't quite understand your point about may-throw -- how > > is may-throw different from a generic side-effect (volatile store, > > syscall etc.)? All of those can't be hoisted or sunk -- we have to >

Sorry, I missed this at first but I have one issue here: On Mon, Jul 18, 2016 at 11:55 AM Sanjoy Das via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi all, > > I think it is time to start getting more concrete here. As a starting > point, I want to send out for review (roughly) the following changes: > > - Add a "gc" address space to the datalayout

Hi Andy, Andrew Trick wrote: > At some point I stopped thinking about this as a bug and realized that > you just need to think of LLVM as modeling speculative code barriers as > memory dependence. In LLVM, it makes no sense to have a readonly > may-throw call. The problem is that that model breaks down with aggressive aliasing like: void foo(int* restrict ptr) { *ptr = 40;

Hi Andy, Andrew Trick wrote: > > I don’t remember why this is important. I often don't know with > InstCombine whether something is needed to expose 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

On Fri, Jul 15, 2016 at 2:44 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi Daniel, > > Daniel Berlin wrote: > > Don't we have the same problems for "exit(0)" > > > > > > This is a noreturn call, so yes, iit has another hidden control > > flow-side-effect of a slightly different kind. GCC models it as an extra >

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

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

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

On Fri, Jul 15, 2016 at 4:00 PM, Andrew Trick <atrick at apple.com> wrote: > > On Jul 15, 2016, at 3:38 PM, Sanjoy Das <sanjoy at playingwithpointers.com> > wrote: > > > Note that this is also necessary to makes post-dominance correct (but we > > already do it in most cases, but i think there are still bugs open about > > correctness) > > Yeah,

> > > LLVM's design decision is one where everything has to explicitly care > about implicit early exits to get correct answers (and not to harp too > much, but "not everything does", years later). If they don't, they will > get wrong answers. > > So, ironically, while looking at this, i noticed it turns out LLVM's PRE in GVN is another place that

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

Okay, so it sounds like it might actually be better to be even more low level, call it "ExtendedBBInfo" or something, and rename what it provides to be more clearly structural: A. Inst * FirstIsGuaranteedToTransferExecutionToSuccessor(BB) (naming bikeshed open on this one :P) B. Inst * LastIsGuaranteedToTransferExecutionToSuccessor(BB) C. Inst *FirstMayThrow(BB) D. Inst

Hi all, In light of recent discussions regarding updating passes to respect convergent semantics, and whether or not it is sufficient for barriers, I would like to propose a change in convergent semantics that should resolve a lot of the identified problems regarding loop unrolling, loop unswitching, etc. Credit to John McCall for talking this over with me and seeding the core ideas. Today,

On Mon, Nov 2, 2015 at 7:19 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Why does this need to be an intrinsic (as opposed to generic "unknown > function" to llvm)? > > Secondly, have you looked into a volatile store / load to an alloca? That > should work with PNaCl and WebAssembly. > > E.g. > > define i32 @blackbox(i32 %arg) { >

The call does not have to be read only, it just has to no alias the load being pre'd. The call may in fact be read/ write of some other memory On Fri, Jul 15, 2016, 5:32 PM Andrew Trick <atrick at apple.com> wrote: > > On Jul 15, 2016, at 5:24 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > >> LLVM's design decision is one where everything has to

(Dropped llvm-dev by accident. Putting it back) HI Eli: >> coro.barrier() doesn't work: if the address of the alloca doesn't escape, >> alias analysis will assume the barrier can't read or write the value of >> the alloca, so the barrier doesn't actually block code movement. Got it. I am new to this and learning a lot over the course of this thread. Thank you