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

Sanjoy Das via llvm-dev llvm-dev at lists.llvm.org
Mon Jul 18 19:34:53 PDT 2016

Hi Peter,

Just to be clear, as a starting point I'm focusing on getting the
no-pointer-to-integer-funny-business bits reviewed and checked in.
The nospeculate bits will have a separate RFC / design review when the
time comes.

Lawrence, Peter wrote:
 >>> Sounds like “volatile” to me …
 >> -- Sanjoy
 > Sanjoy,
 >               Thanks.  So it sounds "volatile"-ish, is it conceptually possible to spell out its
 > semantics in detail ?   if so then it might sound like a (yet another) attribute "like" volatile.

The semantic constraint is about safety.  The safety of nospeculate
loads and stores don't just depend on the physical dereferenceability
of the memory location (and in case of stores, thread-locality), but
on some unknown external source.  This means you can't speculate

   %x = alloca;  // x is dereferenceable
   if (cond)
     %y = load nospeculate %x


   %x = alloca;
   %y = load nospeculate %x
   if (cond)

so in that way it _is_ like volatile.  However, as I said before, you
can still DCE unused loads, DSE stores, forward loads to loads,
forward stores to loads etc.

 > IE basically I'm agreeing with #2, and you don't need to spell it out in detail just
 > for my sake, I'm really asking "can it be spelled out in detail" when it comes to
 > documenting the IR, such that someone writing an optimization pass will be able
 > to do the right thing.

Initially the rule will be: you cannot speculate nospeculate loads or
stores, period (that is, a transform cannot cause a 'nospeculate'
load/store to execute in a situation that it would not have previously
executed in).  Over time we will add a metadata based scheme that
elucidates _why_ a load or store instruction is nospeculate
(e.g. "load nospeculate ... !gc", or something like that) and add
support to LLVM to speculate them in cases that are legal.

-- Sanjoy

More information about the llvm-dev mailing list