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

[Sanjoy Das via llvm-dev]

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