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

[Sanjoy Das via llvm-dev]

Hi Andy,

Andrew Trick wrote:
 >> But for the purposes of this discussion, only the legality (or lack
 >> thereof) of the above transform matters, not whether it is profitable
 >> or not.
 >
 > Given that you will need to disable the transform for GCRefs, it’s 
interesting that if it’s only something that needs to run before ISEL 
then you’re not actually losing any optimization.

Ah, okay; that makes sense.

 >>> If you can come up with an IR design for tracking your GCRef load
 >>> depedencies (usually on specific null and type checks), then that could
 >> That sounds orthogonal to this proposal -- as a starting point we need
 >> a simple way to mark a GCRef load as control dependent on every
 >> condition executed since the start of the program.  Something like
 >> cast-to-dereferenceable can possibly be added once we start
 >> upstreaming analyses that prove that a GCRef load is safe to
 >> speculate, but that's for better performance not correctness.
 >
 > I thought your frontend would know which conditions guard each field 
access.

At a theoretical level it does, but in practice that kind of control
dependence can be difficult to split apart from "normal" control
dependence.

For instance, if we have:

   interface I {
     void func();
   }

   class F {
     Object o;
     void func() {
       Object val = this.o;
     }
   }

   class G {
     public static void f(I instance) {
       instance.func();
     }
   }

then when compiling func() separately there is nothing the load of val
is control dependent on, but in G::f if we do some form of predicated
devirtualization and then inline the body of F::func then the safety
of the load is predicated on the devirtualization predicate passing
too.  If the predicated devirt. was itself conditional on some control
flow based type refinement, then the safety of the load is control
dependent on that control flow as well, and so on.

[snip]

-- Sanjoy