<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 7, 2021 at 8:40 AM David Chisnall 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 04/05/2021 19:32, Tom Stellard via llvm-dev wrote:<br>
> I think requiring an address space would be too confusing for a majority <br>
> of use<br>
> cases.  Would it help if instead of defaulting to 0, the default address <br>
> space<br>
> was target dependent?<br>
<br>
For CHERI targets, the default address space is ABI dependent: AS0 is a <br>
64-bit integer that's relative to the default data capability, AS200 is <br>
a 128-bit capability (on 64-bit platforms).  It can also differ between <br>
code, heap, and stack.<br>
<br>
If this is purely a syntactic thing in the text serialisation, would it <br>
be possible to put something in the DataLayout that is ignored by <br>
everything except the pretty-printer / parser?<br></blockquote><div>Could you give an example?</div><div><br></div><div><br></div><div>Also, perhaps we should separate the opaque pointer types transition from any changes to address spaces. Currently the proposal is basically unchanged from the current status quo in terms of pointer address spaces. We definitely should have a "default" pointer type in some shape or form which is represented by "ptr", or else writing IR tests is too cumbersome. Currently that means AS0, but we can change that in the future if we want independently of opaque pointers.</div></div></div>