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

JF Bastien jfb at google.com
Fri Apr 4 10:54:26 PDT 2014


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>


More information about the llvm-dev mailing list