llvm dev - Apr 2014 - [LLVMdev] 32bit pointers on a (pure) 64bit architecture

Hi,

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.

On the frontend, I do not encounter any issues, but when I provide a
  ...
  "p:32:32:32"
  ...
DataLayout specification to the backend, things get ugly:
- SelectionDag is producing a mix of 64bit and 32bit nodes, and it seems
that a number of
necessary legalizations/promotions are missing.

After adding support for 'PromoteIntRes_GlobalAddress(...)', I get a
failure, because a 'store' node now has a mix of operands:
- some of the operands were already 'i64' from the beginning,
- others were 'i32' (due to the 32bit pointers) and have been promoted
to
'i64'

Because of the latter, the 'PromoteIntOp_STORE' is called. This uses
'GetPromotedInteger' to access the operands.
But, GetPromotedInteger fails if the operand was not promoted. So it fails
on the operands of the 'store' that were already legal (i64).

What would be the recommended way to fix this ?
(Or did I miss something, and should 32bit pointers on a 64bit architecture
be done in a completely different way)

Greetings,

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

----- Original Message -----
> From: "Jeroen Dobbelaere" <jeroen.dobbelaere at gmail.com>
> To: LLVMdev at cs.uiuc.edu
> Sent: Thursday, April 3, 2014 5:31:13 PM
> Subject: [LLVMdev] 32bit pointers on a (pure) 64bit architecture
> 
> Hi,
> 
> 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.
> 
> 
> On the frontend, I do not encounter any issues, but when I provide a
> ...
> "p:32:32:32"
> ...
> 
> DataLayout specification to the backend, things get ugly:
> 
> - SelectionDag is producing a mix of 64bit and 32bit nodes, and it
> seems that a number of
> necessary legalizations/promotions are missing.
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
> 
> 
> After adding support for 'PromoteIntRes_GlobalAddress(...)', I get
a
> failure, because a 'store' node now has a mix of operands:
> 
> - some of the operands were already 'i64' from the beginning,
> 
> - others were 'i32' (due to the 32bit pointers) and have been
> promoted to 'i64'
> 
> 
> Because of the latter, the 'PromoteIntOp_STORE' is called. This
uses
> 'GetPromotedInteger' to access the operands.
> 
> But, GetPromotedInteger fails if the operand was not promoted. So it
> fails on the operands of the 'store' that were already legal (i64).
> 
> 
> What would be the recommended way to fix this ?
> 
> (Or did I miss something, and should 32bit pointers on a 64bit
> architecture be done in a completely different way)
> 
> 
> 
> Greetings,
> Jeroen Dobbelaere
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

On 04/03/2014 03:31 PM, Jeroen Dobbelaere wrote:
> Hi,
>
> 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.
>
> On the frontend, I do not encounter any issues, but when I provide a
>   ...
>   "p:32:32:32"
>   ...
> DataLayout specification to the backend, things get ugly:
> - SelectionDag is producing a mix of 64bit and 32bit nodes, and it 
> seems that a number of
> necessary legalizations/promotions are missing.
>
> After adding support for 'PromoteIntRes_GlobalAddress(...)', I get
a
> failure, because a 'store' node now has a mix of operands:
> - some of the operands were already 'i64' from the beginning,
> - others were 'i32' (due to the 32bit pointers) and have been
promoted
> to 'i64'
>
> Because of the latter, the 'PromoteIntOp_STORE' is called. This
uses
> 'GetPromotedInteger' to access the operands.
> But, GetPromotedInteger fails if the operand was not promoted. So it 
> fails on the operands of the 'store' that were already legal (i64).
>
> What would be the recommended way to fix this ?
> (Or did I miss something, and should 32bit pointers on a 64bit 
> architecture be done in a completely different way)
>
How are you implementing GlobalAddress?

R600/SI has both 32-bit and 64-bit pointers, and (sort of) 64-bit 
registers if you want to see how it handles it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140403/b09e1ced/attachment.html>

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>

On 3 Apr 2014, at 23:44, Hal Finkel <hfinkel at anl.gov> wrote:
> 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.
Presumably pointers are also only 32 bits in memory.  I'm not quite sure
what the issue here is though, because the DataLayout string just defines
in-memory representations.  In particular, it *doesn't* differentiate
between the size and the range of a pointer[1].

When you get to the back end, you can just do zero extension of pointer loads. 
This is slightly tricky, because SelectionDAG is very keen on throwing away the
fact that something is a pointer, but the same type legalisation that works for
unsigned 32-bit integers should apply to pointers...

David

[1] I have some patches that do this, for fat pointer support.

PNaCl does exactly this: all its targets are le32, including x86-64. Intel
also had a patch (which didn't make it into LLVM) which added x32 to LLVM.

You may want to look at both of these.


On Thu, Apr 3, 2014 at 3:31 PM, Jeroen Dobbelaere <
jeroen.dobbelaere at gmail.com> wrote:
> Hi,
>
> 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.
>
> On the frontend, I do not encounter any issues, but when I provide a
>   ...
>   "p:32:32:32"
>   ...
> DataLayout specification to the backend, things get ugly:
> - SelectionDag is producing a mix of 64bit and 32bit nodes, and it seems
> that a number of
> necessary legalizations/promotions are missing.
>
> After adding support for 'PromoteIntRes_GlobalAddress(...)', I get
a
> failure, because a 'store' node now has a mix of operands:
> - some of the operands were already 'i64' from the beginning,
> - others were 'i32' (due to the 32bit pointers) and have been
promoted to
> 'i64'
>
> Because of the latter, the 'PromoteIntOp_STORE' is called. This
uses
> 'GetPromotedInteger' to access the operands.
> But, GetPromotedInteger fails if the operand was not promoted. So it fails
> on the operands of the 'store' that were already legal (i64).
>
> What would be the recommended way to fix this ?
> (Or did I miss something, and should 32bit pointers on a 64bit
> architecture be done in a completely different way)
>
> Greetings,
>
> Jeroen Dobbelaere
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140404/ad5afe2f/attachment.html>