<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Jul 18, 2016 at 4:57 PM Sanjoy Das <<a href="mailto:sanjoy@playingwithpointers.com">sanjoy@playingwithpointers.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Chandler,<br>
<br>
On Mon, Jul 18, 2016 at 4:46 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>> wrote:<br>
> Sorry, I missed this at first but I have one issue here:<br>
><br>
> I think everything here should apply to *all* non-zero address spaces. I<br>
> think the thing we would want is for a tagged address space to opt *out* of<br>
> this conservative behavior, not the other way around.<br>
<br>
It isn't just conservative behavior though, I'm disallowing `inttoptr`<br>
and `ptrtoint` at the type system level.  If we flip the default then<br>
this change will then no longer be backwards compatible, and will<br>
break out of tree targets.<br></blockquote><div><br></div><div>I understand that we need some way of handling inttoptr stuff, but I can see good ways of doing this even with an "opt in" strategy using auto-upgrade.</div><div><br></div><div>We could auto-upgrade code to addrspace cast to address space 0 and then do ptrtoint (and vice versa).</div><div><br></div><div>But I'm all in favor of making this change, just arguing that the semantics should be the other way around.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> So I don't think you need a tagged address space to implement everything<br>
> here, and I'd like to avoid tagging the address space until the last<br>
> possible second to make sure that this is implemented as generically as<br>
> possible. I'm actually hopeful that the tagging isn't necessary at all.<br>
<br>
Won't that be stalled on every user of non-zero address spaces<br>
agreeing on these semantics (e.g. on that they don't need `inttoptr`<br>
for instance)?  No one has so far stepped forth to discuss the<br>
semantics they need -- though this could have to do with the subject<br>
line though.<br>
<br>
I can call the tag something more generic than "GC" if you wish (in<br>
fact, that was the reason for keeping the first patch trivial, to hash<br>
these things out :) ), but it seems friendlier to start with<br>
explicitly enumerating the address space(s?) that need the<br>
no-integer-conversion properties, and flip the default once the<br>
changes have circulated more widely and people have had a chance to<br>
experiment.<br></blockquote><div><br></div><div>Given how few users of non-zero address space pointers there are I actually am not sure about this. Maybe you do need a separate thread to make it clear that we're considering changing the defaults for address spaces, but I personally much prefer the constructively correct approach where once you are outside of address space zero, there *is* no integer mapping available unless people need one and opt into having that behavior.</div><div><br></div><div>There are relatively few such users though, so i feel like you could likely start a fresh thread and collect them pretty quickly if this in practice isn't the right tradeoff.</div><div><br></div><div>Either way the defaults go, I'd also prefer that the description be about the semantics not about the use case. So I'd suggest a flag indicating an address space has an integer mapping (or that it doesn't have such a mapping) rather than one that talks about GC.</div><div><br></div><div>-Chandler</div><div> </div></div></div>