llvm dev - Jul 2016 - RFC: Strong GC References in LLVM

On Thu, Jul 14, 2016 at 4:48 PM Sanjoy Das via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi all,
>
> It looks like the key controversial point is the bit about the extra
> control dependence on loads and stores[0].  Generally the consensus is
> that (please chime if you think otherwise) it is not reasonable to
> make the safety (or semantics) of a load instruction depend on the
> type it is loading.  Introducing such a thing would involve changing
> the IR semantics in a fundamental way, and therefore has a high bar
> for acceptance.
>
> Here is a summary of the alternative solutions that were proposed here
> and on IRC (thanks Chandler, Andy, Eli!):
>
Thanks for writing up the summary, sorry I didn't summarize #2 for you as I
had promised. ;]

>   2. Introduce a flag on load and stores that either
>        a. Denotes a "gc_safety" control dependence.
>        b. Denotes a "blackbox_safety" control dependence.  In
this case
>           we will probably have some optional metadata on loads and
>           stores to indicate that the control dependence is actually on
>           GC safety.
>
Suggested name for 2b: "unsafe" or "predicated".
Essentially, that the load
is not generally safe to do even if the *memory* is generally safe to load
from because of some external effect.

>
>      As a starting point, LLVM will conservatively not speculate such
>      loads and stores; and will leave open the potential to upstream
>      logic that will have a more precise sense of when these loads and
>      stores are safe to speculate.
>
>   3. Introduce a general way to denote control dependence on loads and
>      stores.  This can be helpful to LLVM in general, and will let us
>      basically implement a more precise version of (2).
>
I actually think there is a pretty clean incremental path from 2a to 3
here. We can start with just the basic "there is something control
dependent about this" and use metadata to experiment with communicating it
to the optimizer. If we come up with something really general and precise,
we can fold it into the blanket thing, but until then we don't scope creep
or put something into the IR.


One thing you didn't mention is that this requires a matching function
attribute too so that we can distinguish between a call site that reads
memory and a call site that reads memory in a way that is potentially
unsafe.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160715/87bb6bf0/attachment.html>

Hi Chandler,

Chandler Carruth wrote:
 > On Thu, Jul 14, 2016 at 4:48 PM Sanjoy Das via llvm-dev
 > <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
 >
 >     Hi all,
 >
 >     It looks like the key controversial point is the bit about the extra
 >     control dependence on loads and stores[0].  Generally the 
consensus is
 >     that (please chime if you think otherwise) it is not reasonable to
 >     make the safety (or semantics) of a load instruction depend on the
 >     type it is loading.  Introducing such a thing would involve changing
 >     the IR semantics in a fundamental way, and therefore has a high bar
 >     for acceptance.
 >
 >     Here is a summary of the alternative solutions that were proposed 
here
 >     and on IRC (thanks Chandler, Andy, Eli!):
 >
 >
 > Thanks for writing up the summary, sorry I didn't summarize #2 for you
 > as I had promised. ;]

No problem; thanks for your help on IRC. :)

 >        2. Introduce a flag on load and stores that either
 >             a. Denotes a "gc_safety" control dependence.
 >             b. Denotes a "blackbox_safety" control dependence. 
In
this case
 >                we will probably have some optional metadata on loads and
 >                stores to indicate that the control dependence is 
actually on
 >                GC safety.
 >
 >
 > Suggested name for 2b: "unsafe" or "predicated".
Essentially, that the

SGTM.

 > load is not generally safe to do even if the *memory* is generally safe
 > to load from because of some external effect.

Yes, that's exactly my intent.

 >           As a starting point, LLVM will conservatively not speculate 
such
 >           loads and stores; and will leave open the potential to upstream
 >           logic that will have a more precise sense of when these 
loads and
 >           stores are safe to speculate.
 >
 >        3. Introduce a general way to denote control dependence on 
loads and
 >           stores.  This can be helpful to LLVM in general, and will 
let us
 >           basically implement a more precise version of (2).
 >
 >
 > I actually think there is a pretty clean incremental path from 2a to 3

Reading the rest of what you wrote, it looks like you meant "from 2b
to 3"?

 > here. We can start with just the basic "there is something control
 > dependent about this" and use metadata to experiment with
communicating
 > it to the optimizer. If we come up with something really general and
 > precise, we can fold it into the blanket thing, but until then we
don't
 > scope creep or put something into the IR.

SGTM.

 > One thing you didn't mention is that this requires a matching function
 > attribute too so that we can distinguish between a call site that reads
 > memory and a call site that reads memory in a way that is potentially
 > unsafe.

Yes, thanks for bringing this up.

One interesting possibility is to not make this function attribute
specific to memory at all.  Then we can use it to communicate "this
function may have undefined behavior", and fearlessly hoist "readnone
nounwind" functions that are not also "unsafe".

-- Sanjoy

On Thu, Jul 14, 2016 at 8:21 PM Sanjoy Das <sanjoy at
playingwithpointers.com>
wrote:
> Hi Chandler,
>
> Chandler Carruth wrote:
>  > I actually think there is a pretty clean incremental path from 2a to
3
>
> Reading the rest of what you wrote, it looks like you meant "from 2b
> to 3"?
>
Doh, yes. Sorry.

>  > One thing you didn't mention is that this requires a matching
function
>  > attribute too so that we can distinguish between a call site that
reads
>  > memory and a call site that reads memory in a way that is potentially
>  > unsafe.
>
> Yes, thanks for bringing this up.
>
> One interesting possibility is to not make this function attribute
> specific to memory at all.  Then we can use it to communicate "this
> function may have undefined behavior", and fearlessly hoist
"readnone
> nounwind" functions that are not also "unsafe".
>
This is ... an extremely interesting idea.

Can you start a separate RFC about this?

I think it is important to understand how these things interact with each
other, but it sounds like they may form a very cohesive whole.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160715/758bd734/attachment.html>