search for: gc_load

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

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

...mantics in a fundamental way, and therefore has a high bar > for acceptance. > > Here is a summary of the alternative solutions that were proposed here > and on IRC (thanks Chandler, Andy, Eli!): > > 1. Model loads and stores of GC references as intrinsic calls: add > llvm.gc_load, llvm.gc_store intrinsics, and optimize them as loads > and stores whenever appropriate and legal. > > 2. Introduce a flag on load and stores that either > a. Denotes a "gc_safety" control dependence. > b. Denotes a "blackbox_safety" control depen...

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

...hold. > > You may be answering this elsewhere in the thread, but are we sure the GC load shouldn’t be an intrinsic? That's what others are leaning towards. I'm somewhat hesitant to do that since it will involved changing almost every place that handles LoadInst to also handle the gc_load intrinsic (and would be a bad thing for the codebase long term), but I'm not 100% opposed to it if that's what we need to move forward. >> ### Lowering >> >> We do not teach LLC about GCREF's at all (in fact, we can change it to >> assert that the datalayout...

This is a proposal to add strong GC reference types to LLVM. We have some local (downstream) patches that are needed to prevent LLVM's optimizer from making transforms that are problematic in the presence of a precise relocating GC. Adding a notion of a strong GC reference to LLVM will let us upstream these patches in a principled manner, and will act as a measure to avoid new problematic