Displaying 4 results from an estimated 4 matches for "gc_safety".
2016 Jul 14
5
RFC: Strong GC References in LLVM
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
2016 Jul 15
2
RFC: Strong GC References in LLVM
...mmary 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.
>
Sugg...
2016 Jul 19
2
RFC: Strong GC References in LLVM
> Hi all,
>
>
> 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
>...
2016 Jul 15
2
RFC: Strong GC References in LLVM
...:
>
> 1. Model loads and stores of GC references as intrinsic calls: add
> llvm.gc_load, llvm.gc_store intrinsics, and optimize them as loads
> and stores whenever appropriate and legal.
>
> 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.
>
>...