[llvm-dev] RFC: Strong GC References in LLVM
Sanjoy Das via llvm-dev
llvm-dev at lists.llvm.org
Mon Jul 11 20:16:23 PDT 2016
Hi Eli,
Eli Friedman wrote:
> What optimizations are you missing? The very fact that it isn't in SSA
> form hurts to some extent... and I guess you want to leverage existing
> optimizations for loads and stores?
Yes, we'd have to "reimplement" basic things like
gcref_store(location, offset, value)
gcref_copy(location_2, location)
value_2 = gcref_store(location_2, offset)
=>
gcref_store(location, offset, value)
gcref_copy(location_2, location)
value_2 = value
etc.
> > but on the flip side, I think you're going
> > to end up chasing down weird problems forever if a "load" from an
> alloca
> > has side-effects.
>
> I need to carefully think through this before committing to it, but I
> think we're generally okay with completely disallowing allocas of
> GCREF type (like we do for token types today). If we could do that
> is your concern addressed?
>
>
> In general, if I think of a GCREF as an unsized handle to an object
> rather than a pointer with weird properties, it's somewhat less scary.
Sure, but we also want to give it some pointer-like attributes, like
alignment, dereferenceable_or_null etc.
> Also, it's more clear how to deal with a GCREF if you explicitly list
> out operations which are legal rather than which operations are
> illegal.
Agreed.
> For example "A GCREF is a new type of value. It does not have
> a representation in memory. You can use GEP on a GCREF. You can load
> or store through a GCREF; this resolves the GCREF to a specific address
> in memory, then acts like a load/store from that address. GCREFs have
> these aliasing rules: [...]. There are GCREF intrinsics for
> constructing and manipulating GCREFs. No other operations on GCREFs are
> allowed."
>
> I guess the bit I'm most worried about is using plain loads to create
> GCREFs, and plain stores to store them. As long as we don't have that,
> existing optimization passes will essentially just work, I think; we
Using a gc_load and gc_store intrinsic would do the job for
correctness, but as I've said before I think we'll end up with some
incidental complexity since almost every place that handles loads or
stores will also have to handle these intrinsics. However, I
personally don't mind doing the work too much if the community is okay
with the (hopefully mostly mechanical) code duplication.
-- Sanjoy
More information about the llvm-dev
mailing list