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

[Hal Finkel]

----- Original Message -----
> From: "Jeroen Dobbelaere" <jeroen.dobbelaere at gmail.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: LLVMdev at cs.uiuc.edu
> Sent: Friday, April 4, 2014 3:54:08 AM
> Subject: Re: [LLVMdev] 32bit pointers on a (pure) 64bit architecture
> 
> 
> 
> 
> 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.

Agreed; but what does your *ISelLowering::getPointerTy() function look like? Did you override the default implementation? I wonder if returning MVT::i64 from this function will make things work for you.

 -Hal

> 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