<div dir="ltr"><div class="gmail_quote"><div>My high-level comment is that I'm not really sure we need a new type here. I'm curious whether we can make non-zero-address-space pointers have the semantics you need in a conservative model.</div><div><br></div><div>The reason I say this is that the requirements you have here actually are very similar to what I would expect other users of custom address spaces to want. While they (and you probably) would have domain *specific* optimizations you would like to perform, the generic optimizer needs to keep its hands off to avoid breaking invariants. Specifically looking at your examples:</div><div dir="ltr"><br></div><div dir="ltr">On Fri, Jun 24, 2016 at 12:23 AM Sanjoy Das via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"># Examples of Bad Transforms<br>
<br>## Integer -> GCREF Conversion<br>
<br>
(%value is unused)<br>
<br>
%value = load i64, i64* %ptr<br>
== Transformed to ==><br>
%value = load GCREF, GCREF* (bitcast %ptr)<br></blockquote><div><br></div><div>I think this should definitely be invalid for non-zero address spaces. Getting a non-zero address space out-of-thin-air is nuts (provided its not a CSE-based transform that proves equivalence as you indicate in your more detailed writeup).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
%value = load i64, i64* %ptr<br>
== Transformed to ==><br>
%value = load i64, i64* %ptr<br>
%value_gc = inttoptr %value to GCREF  (%value_gc unused)<br></blockquote><div><br></div><div>And here as well. We shouldn't (IMO) be adding out-of-thin-air address spaces, and definitely not inttoptr operations on them!!!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">## GCREF -> Integer conversion<br></blockquote><div><br></div><div>I thought non-zero address spaces already made this flat out impossible? THis is really not OK for many users of address spaces...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
## Round tripping GCREF's through Integers<br></blockquote><div><br></div><div>Same as above. Many non-zero address spaces don't have integer representations that are meaningful I thought? This doesn't seem an unreasonable requirement to me honestly...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">## Bad types due to hoisting loads out of control flow<br>
<br>
This is bad<br>
<br>
if (is_reference) {<br>
  %val = load GCREF, GCREF* %ptr<br>
}<br>
== Transformed to ==><br>
%val = load GCREF, GCREF* %ptr<br>
if (is_reference) {<br>
}<br>
<br>
unless the compiler can prove that %val is a GC reference at its new<br>
location.  Downstream we model the Java type system in LLVM IR to try<br>
to prove that %val is a GC reference in its new location, but for<br>
starters we will have to be conservative upstream.<br></blockquote><div><br></div><div>I think this is the interesting thing. It is essentially saying that loads of a non-zero address space pointer are control dependent which I don't think is necessarily true with our current definitions of address spaces, but I think this might be a very reasonable desire.</div><div><br></div><div>If anything, we might want something in the datalayout that identifies whether particular address spaces can be speculatively loaded from. This is not terribly dissimilar from the memory scopes proposal which essentially wants to provide some encoding of basic transformations to non-zero address spaces that are allowed while keeping everything else conservative by default.</div><div><br></div><div>Personally, I'd be happy to make the default even more conservative to address the GC use case and add a mechanism to opt out of that for GPUs and other users that want very generic transforms to continue applying.</div><div><br></div><div><br></div><div>So I'm curious whether this seems reasonable to you (and others). To summarize: make address spaces sufficiently conservative by default to satisfy the requirements for GC pointers, and add "opt-in" mechanisms for generic transforms that existing users of non-zero address spaces actually desire.</div><div><br></div><div>Alternatively, I'm interested in any<span style="line-height:1.5"> examples that more firmly illustrate the reasons why address spaces are fundamentally the wrong *model* for GC pointers.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">-Chandler</span></div></div></div>