[llvm-dev] RFC: Strong GC References in LLVM

[Chandler Carruth via llvm-dev]

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>