<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Hi Hal,<br><br>On Fri, Apr 4, 2014 at 12:44 AM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>----- Original Message -----<br>
> From: "Jeroen Dobbelaere" <<a href="mailto:jeroen.dobbelaere@gmail.com">jeroen.dobbelaere@gmail.com</a>><br>[... ]<br></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>> I am trying to get llvm working for an architecture that has 64bit<br>
> registers, but 32bit addresses.<br>
> Because of that, I want the pointers to also be 32bit, although they<br>
> will live in a 64 bit register.<br>
><br>
[...] <br></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">
</div>I don't understand why you're doing this. If the pointers live in 64-bit registers, why don't you just consider them to be 64-bit pointers? The fact that the upper 32 bits will always be zero does not seem like something you'd need to worry about (although there are certainly some optimizations that can be done later). Frontend issues, like the fact that ptrdiff_t is only 32 bits, seem like an independent concern.<br>

<br>
 -Hal<br>
<div><br>
</div></blockquote><div><div><div><div><div><br>The main reason to do 
this, is to use less space for a pointer. This reflects then in the size
 of structs that use pointers etc...<br><br></div>As the layout of a 
structure is based on the DataLayout string, Both the DataLayout of 
clang and of the backend need to be kept in sync:<br></div>- When I 
provide 32bit pointers to clang, but 64bit pointers to the backend, the 
frontend and middle end are indeed making use of 32bit pointers. But 
from the moment that a pointer member needs to be accessed (by the 
backend), the offset is wrong (as it suddenly assumes 64bit pointers).<br><br></div><div>(Like in  'struct Foo { int bar; struct Foo* next; struct Foo* prev; } )<br></div><div><br></div>So, that's why I believe the the right way to handle this, is by specifying "p:32:32:32" in both datalayout strings.<br>
</div>The
 fact that because of this, llvm is producing a selection dag that 
cannot be handled by legalization seems more like a bug to me.. and I 
would like to find out what the recommend way is to fix this.<br>[...]<br></div><div><br>Greetings,<br><br>Jeroen Dobbelaere </div></div></div></div>