llvm dev - Jul 2016 - RFC: Strong GC References in LLVM

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 string
>
I don't really understand the need for this yet, because the following
point:

>   - Start implementing the non-controversial rules (i.e. everything
>     except the bits that initiated the "nospeculate" attribute
>     discussion):
>
I think everything here should apply to *all* non-zero address spaces. I
think the thing we would want is for a tagged address space to opt *out* of
this conservative behavior, not the other way around.

So I don't think you need a tagged address space to implement everything
here, and I'd like to avoid tagging the address space until the last
possible second to make sure 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 need, and even if all we do is
> implement those, we will be in a better position overall.
>
>
> One thing I want a design opinion on (already discussed on IRC): I'm
> planning to phrase RewriteStatepointsForGC (a ModulePass) that
> "implements" GC references "in terms of" normal
pointers.  One way to
> do this is to rewrite each def and user of GC refs to use a normal
> pointer, but that's unnecessary data structure churn, so I was
> wondering if instead we can flip the meaning of what a GC ref is by
> modifying the datalayout instead?  RewriteStatepointsForGC can then be
> seen as changing IR that can be lowered to run on only a
"machine"
> that directly supports GC pointers to IR that can be lowered to run on
> machines that don't.  That is RewriteStatepointsForGC will change IR
> from
>
> "No explicit relocations, addrspace(k) is marked as 'gc' in
the
> datalayout" to "All relocations explicit, addrspace(k) is not
marked
> specially in the datalayout"
>
> However, Chandler had some (strong?) reservations on IRC about
> modifying datalayout in an optimization, in the face of which I have a
> couple of alternatives:
>
>   - Have RewriteStatepointsForGC rewrite defs and users of GC
>     references to use a "normal" pointer type.  I'm a little
hesitant
>     to to do this since it seems wasteful (no evidence yet that it will
>     matter), and may complicate keeping side data structures correct in
>     the face of mass invalidations.
>
>   - Represent the gc address space in something other than the
>     datalayout that we all can agree is fair game to be modified by a
>     ModulePass.  Not a great option since datalayout seems the most
>     natural place to put the "gc-ref-addrspace" information.
>
>   - Don't do anything, i.e. RewriteStatepointsForGC does what it does
>     today: it rewrites pointers of addrspace(1) (or addrspace(k) for
>     some k) to be explicit but does not change the meaning of
>     "addrspace(k)".  I'm hesitant to do this because then I
can't
>     concisely answer "what does RewriteStatepointsForGC do?".
>
> I want to see what others think about this, but in the absence of any
> specific opinion here I'll go with the first option (and consider
> using mutateType if things turn out to be too slow).
>
>
>
>
> In parallel with all this, I'll try to come up with a concrete notion
> of how the nospeculate attributes on loads and function calls will
> look like, how it would interact with optimizations like mem2reg etc.
> I'll consider potential interactions with
> https://reviews.llvm.org/D20116 "Add speculatable function
attribute"
> and generally just kick it around to see if the idea holds up and
> gives us all of the constraints we need.
>
> Sounds good?
> -- Sanjoy
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160718/11cba3a0/attachment.html>

Hi Chandler,

On Mon, Jul 18, 2016 at 4:46 PM, Chandler Carruth <chandlerc at
google.com> wrote:
> Sorry, I missed this at first but I have one issue here:
>
> I think everything here should apply to *all* non-zero address spaces. I
> think the thing we would want is for a tagged address space to opt *out* of
> this conservative behavior, not the other way around.
It isn't just conservative behavior though, I'm disallowing `inttoptr`
and `ptrtoint` at the type system level.  If we flip the default then
this change will then no longer be backwards compatible, and will
break out of tree targets.

I can make the type system changes last (and lead with the other
subtler fixes), but I do want to make them at some point.  This one of
the things we disallow in our tree downstream, and we'd like to
upstream the logic.
> So I don't think you need a tagged address space to implement
everything
> here, and I'd like to avoid tagging the address space until the last
> possible second to make sure that this is implemented as generically as
> possible. I'm actually hopeful that the tagging isn't necessary at
all.
Won't that be stalled on every user of non-zero address spaces
agreeing on these semantics (e.g. on that they don't need `inttoptr`
for instance)?  No one has so far stepped forth to discuss the
semantics they need -- though this could have to do with the subject
line though.

I can call the tag something more generic than "GC" if you wish (in
fact, that was the reason for keeping the first patch trivial, to hash
these things out :) ), but it seems friendlier to start with
explicitly enumerating the address space(s?) that need the
no-integer-conversion properties, and flip the default once the
changes have circulated more widely and people have had a chance to
experiment.

-- Sanjoy

On Mon, Jul 18, 2016 at 4:57 PM Sanjoy Das <sanjoy at
playingwithpointers.com>
wrote:
> Hi Chandler,
>
> On Mon, Jul 18, 2016 at 4:46 PM, Chandler Carruth <chandlerc at
google.com>
> wrote:
> > Sorry, I missed this at first but I have one issue here:
> >
> > I think everything here should apply to *all* non-zero address spaces.
I
> > think the thing we would want is for a tagged address space to opt
*out*
> of
> > this conservative behavior, not the other way around.
>
> It isn't just conservative behavior though, I'm disallowing
`inttoptr`
> and `ptrtoint` at the type system level.  If we flip the default then
> this change will then no longer be backwards compatible, and will
> break out of tree targets.
>
I understand that we need some way of handling inttoptr stuff, but I can
see good ways of doing this even with an "opt in" strategy using
auto-upgrade.

We could auto-upgrade code to addrspace cast to address space 0 and then do
ptrtoint (and vice versa).

But I'm all in favor of making this change, just arguing that the semantics
should be the other way around.

> > So I don't think you need a tagged address space to implement
everything
> > here, and I'd like to avoid tagging the address space until the
last
> > possible second to make sure that this is implemented as generically
as
> > possible. I'm actually hopeful that the tagging isn't
necessary at all.
>
> Won't that be stalled on every user of non-zero address spaces
> agreeing on these semantics (e.g. on that they don't need `inttoptr`
> for instance)?  No one has so far stepped forth to discuss the
> semantics they need -- though this could have to do with the subject
> line though.
>
> I can call the tag something more generic than "GC" if you wish
(in
> fact, that was the reason for keeping the first patch trivial, to hash
> these things out :) ), but it seems friendlier to start with
> explicitly enumerating the address space(s?) that need the
> no-integer-conversion properties, and flip the default once the
> changes have circulated more widely and people have had a chance to
> experiment.
>
Given how few users of non-zero address space pointers there are I actually
am not sure about this. Maybe you do need a separate thread to make it
clear that we're considering changing the defaults for address spaces, but
I personally much prefer the constructively correct approach where once you
are outside of address space zero, there *is* no integer mapping available
unless people need one and opt into having that behavior.

There are relatively few such users though, so i feel like you could likely
start a fresh thread and collect them pretty quickly if this in practice
isn't the right tradeoff.

Either way the defaults go, I'd also prefer that the description be about
the semantics not about the use case. So I'd suggest a flag indicating an
address space has an integer mapping (or that it doesn't have such a
mapping) rather than one that talks about GC.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160719/d3523c94/attachment.html>