[llvm-dev] RFC: Strong GC References in LLVM
Sanjoy Das via llvm-dev
llvm-dev at lists.llvm.org
Mon Jul 18 16:56:49 PDT 2016
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
More information about the llvm-dev
mailing list