<div dir="ltr">+1<br><div>Sounds like a good plan to me</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 18, 2016 at 11:54 AM, Sanjoy Das <span dir="ltr"><<a href="mailto:sanjoy@playingwithpointers.com" target="_blank">sanjoy@playingwithpointers.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
I think it is time to start getting more concrete here.  As a starting<br>
point, I want to send out for review (roughly) the following changes:<br>
<br>
 - Add a "gc" address space to the datalayout string<br>
 - Start implementing the non-controversial rules (i.e. everything<br>
   except the bits that initiated the "nospeculate" attribute<br>
   discussion):<br>
    - No pointer <-> integer casts for GC address spaces to begin with<br>
    - Add an intrinsic (with control dependence) to<br>
      convert GCrefs -> integers (we need this for GC load/store<br>
      barriers)<br>
    - Disable some of the problematic "cast by round tripping through<br>
      memory" type optimizations for loads and stores that are of GC<br>
      ref type<br>
<br>
The things above are things we know we need, and even if all we do is<br>
implement those, we will be in a better position overall.<br>
<br>
<br>
One thing I want a design opinion on (already discussed on IRC): I'm<br>
planning to phrase RewriteStatepointsForGC (a ModulePass) that<br>
"implements" GC references "in terms of" normal pointers.  One way to<br>
do this is to rewrite each def and user of GC refs to use a normal<br>
pointer, but that's unnecessary data structure churn, so I was<br>
wondering if instead we can flip the meaning of what a GC ref is by<br>
modifying the datalayout instead?  RewriteStatepointsForGC can then be<br>
seen as changing IR that can be lowered to run on only a "machine"<br>
that directly supports GC pointers to IR that can be lowered to run on<br>
machines that don't.  That is RewriteStatepointsForGC will change IR<br>
from<br>
<br>
"No explicit relocations, addrspace(k) is marked as 'gc' in the<br>
datalayout" to "All relocations explicit, addrspace(k) is not marked<br>
specially in the datalayout"<br>
<br>
However, Chandler had some (strong?) reservations on IRC about<br>
modifying datalayout in an optimization, in the face of which I have a<br>
couple of alternatives:<br>
<br>
 - Have RewriteStatepointsForGC rewrite defs and users of GC<br>
   references to use a "normal" pointer type.  I'm a little hesitant<br>
   to to do this since it seems wasteful (no evidence yet that it will<br>
   matter), and may complicate keeping side data structures correct in<br>
   the face of mass invalidations.<br>
<br>
 - Represent the gc address space in something other than the<br>
   datalayout that we all can agree is fair game to be modified by a<br>
   ModulePass.  Not a great option since datalayout seems the most<br>
   natural place to put the "gc-ref-addrspace" information.<br>
<br>
 - Don't do anything, i.e. RewriteStatepointsForGC does what it does<br>
   today: it rewrites pointers of addrspace(1) (or addrspace(k) for<br>
   some k) to be explicit but does not change the meaning of<br>
   "addrspace(k)".  I'm hesitant to do this because then I can't<br>
   concisely answer "what does RewriteStatepointsForGC do?".<br>
<br>
I want to see what others think about this, but in the absence of any<br>
specific opinion here I'll go with the first option (and consider<br>
using mutateType if things turn out to be too slow).<br>
<br>
<br>
<br>
<br>
In parallel with all this, I'll try to come up with a concrete notion<br>
of how the nospeculate attributes on loads and function calls will<br>
look like, how it would interact with optimizations like mem2reg etc.<br>
I'll consider potential interactions with<br>
<a href="https://reviews.llvm.org/D20116" rel="noreferrer" target="_blank">https://reviews.llvm.org/D20116</a> "Add speculatable function attribute"<br>
and generally just kick it around to see if the idea holds up and<br>
gives us all of the constraints we need.<br>
<br>
Sounds good?<span class="HOEnZb"><font color="#888888"><br>
-- Sanjoy<br>
</font></span></blockquote></div><br></div>