[LLVMdev] 32bit pointers on a (pure) 64bit architecture
Hal Finkel
hfinkel at anl.gov
Fri Apr 4 08:44:39 PDT 2014
----- 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 10:37:13 AM
> Subject: Re: [LLVMdev] 32bit pointers on a (pure) 64bit architecture
>
>
>
>
>
>
>
> On Fri, Apr 4, 2014 at 5:19 PM, Hal Finkel < hfinkel at anl.gov > wrote:
>
>
> [..]
>
>
> > Is this difference indeed what we would need to expect at this
> > level
> > ?
> > - should we learn the selection dag creator to use the first larger
> > or equal valid type (i64) here ?
> >
> > - or should we make sure that the legalization phase accepts the
> > mix
> > of types that is produced in that case ?
>
> Is i32 a legal type? In the PowerPC backend, in 64-bit mode, we have
> 32-bit subregisters of the 64-bit registers, and both i32 and i64
> are legal types. I suspect that if you do something similar, things
> will work for you.
>
> -Hal
>
>
>
>
> On this architecture, i32 is _not_ a legal type. I can take a look at
> that, but I was trying to avoid it :(.
Fair enough. I think that, although it will involve some extraneous messiness in your register definitions, it should not actually be that bad. You'll want to set most of the operation actions to Promote in your *ISelLowering.cpp file, promoting them to i64. There are probably some hidden assumptions that ADD is always available for all legal types, but that's not a huge problem because, like AND, OR, etc. ADD on the 32-bit 'sub-regsters' can be done with a pattern using the 64-bit instruction (again, the PowerPC backend does exactly this).
All of this, however, does come with some advantages. Because the DAGCombiner and later passes will "understand" the 32-bit nature of the pointer values, it will be able to fold away some masking operations without you needing to do anything special.
-Hal
>
>
> Greetings,
> --
> Jeroen Dobbelaere
>
--
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
More information about the llvm-dev
mailing list