<div dir="ltr"><div>Sorry, this thread disappeared into my email filters. </div><div><br></div>So to clarify/summarize, the proposed change here is to change the x86 backend data layout to encode the pointer sizes for these three address spaces. It seems like there's general agreement that this is fine, as long as there aren't other changes to the 'middle end'--</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 31, 2019 at 10:44 AM Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</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"><div dir="ltr"><div dir="ltr">On Wed, Jul 31, 2019 at 10:29 AM Philip Reames via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF">
    <p>Looks like I made my point in an accidentally really confusing
      way.  Let me try again w/Matt's correction in mind.</p>
    <p>I want to make sure that the middle end optimizer code is *driven
      by the data layout*.  I am not trying to express an opinion on how
      that data layout is populated (frontend, backedge, black magic,
      what have you).  I just want to make sure that we don't end with
      the middle end having to know that address space "56" has special
      meaning beyond what is encoded in the data layout.  To say it
      differently, I want to make sure that a different frontend
      targeting a different backend is not effected by the proposed
      changes.</p></div></blockquote><div>Got it. :) Yes, we have no intention of teaching the middle end about these address spaces. The usual rules around addrspacecast should apply.<br></div></div></div>
</blockquote></div>