<div dir="ltr"><div dir="ltr">On Wed, Jul 31, 2019 at 9:26 AM Arsenault, Matthew via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">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>
<div style="direction:ltr">
<div>The datalayout itself is currently not considered a point of configurability. It’s a static, backend/codegen defined property. The target machine machine returns the datalayout for the given triple and is the source of truth. The front end is responsible
 for creating a module with an exactly matching datalayout and is not free to customize the datalayout this way. I’m not sure what there is to gain by avoiding putting this information in the backend.</div></div></div></blockquote><div><br></div><div>I agree with everything here, but did you mean frontend instead of backend in the last sentence? As a consequence of the fact that each target defines its data layout, that means we have to put the new data layout in the backend and the frontend if we are going to use address spaces. </div><div><br></div><div>We could implement this purely in the frontend with ptrotoint / inttoptr, zext, sext, trunc, i32, i64 etc, but the IR for it is quite awful and unoptimizable. It breaks several invariants and the extension seems to be naturally representable with address spaces.</div></div></div>