[LLVMdev] 32bit pointers on a (pure) 64bit architecture

[Jeroen Dobbelaere]

Hi Hal,

On Fri, Apr 4, 2014 at 12:44 AM, Hal Finkel <hfinkel at anl.gov> wrote:

> ----- Original Message -----
> > From: "Jeroen Dobbelaere" <jeroen.dobbelaere at gmail.com>
> [... ]
>
> I am trying to get llvm working for an architecture that has 64bit
> > registers, but 32bit addresses.
> > Because of that, I want the pointers to also be 32bit, although they
> > will live in a 64 bit register.
> >
> [...]
>
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.
>
>  -Hal
>
>
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...

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:
- 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).

(Like in  'struct Foo { int bar; struct Foo* next; struct Foo* prev; } )

So, that's why I believe the the right way to handle this, is by specifying
"p:32:32:32" in both datalayout strings.
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.
[...]

Greetings,

Jeroen Dobbelaere
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140404/c98f109d/attachment.html>