<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 20, 2020 at 3:44 PM Alexander Richardson via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">arichardson added a comment.<br>
<br>
In D70947#2408741 <<a href="https://reviews.llvm.org/D70947#2408741" rel="noreferrer" target="_blank">https://reviews.llvm.org/D70947#2408741</a>>, @echristo wrote:<br>
<br>
> Why is this useful rather than having targets set the address space used in the backend explicitly? i.e. how is what amdgpu was doing up to this point not ok? It's not really clear here.<br>
<br>
That's fine for globals created in target-specific passes, but other passes that create new global variables need to know which address space to place them in. In our CHERI fork (using a default address space of 200), we got lots of assertion failures/invalid IR due to passes creating globals in AS0 (or assuming that all global pointers are AS0) until I added a default globals address space to the datalayout so  those passes can choose the address space that our target needs. Does that make sense?<br></blockquote><div><br></div><div>It does. It highlights a problem that tools aren't forward compatible though :) I think it's fine, it's just a little annoying.</div><div><br></div><div>Arguably this is a major enough change that it should have gone to llvm-dev as well. Would you mind sending that note letting people know what you've done? You may get rollback requests, but changing the data layout string is a major change.</div><div><br></div><div>-eric </div></div></div>