[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 10:07:07 AM
> Subject: Re: [LLVMdev] 32bit pointers on a (pure) 64bit architecture
> 
> 
> Hi Hal,
> 
> 
> 
> 
> 
> On Fri, Apr 4, 2014 at 1:22 PM, Hal Finkel < hfinkel at anl.gov > wrote:
> 
> 
> [..]
> 
> 
> 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
> 
> 
> 
> 
> 
> I actually missed implementing this one. But, depending on the
> testcase that I use,
> 
> implementing it has no or worse effect:
> 
> 
> I now get assertion errors complaining of different value sizes,
> coming from the
> 
> difference between the datalayout (ptrsize:i32) and the pointerty
> (size overruled to i64).
> 
> in SelectionDag::InferPtrAlignment.
> 
> I also found out the this method is not called at all (for my
> (failing) tests) during the initial selection dag buildup.
> 
> 
> Note:
> - most of my testing is done on llvm-3.3, but I verified that the
> same issues are there for llvm-3.4
> 
> - I did implement:
> virtual MVT getScalarShiftAmountTy(EVT LHSTy) const { return
> MVT::i64; }
> 
> although I have no good idea why the default for that is mapped to
> the pointer type...
> 
> 
> In the following sample:
> - if full 64bit pointers are used, XXXi32 will be 'i64' and
> everything legalizes/compiles fine
> - if 32bit pointers are used, XXXi32 will be 'i32' and legalization
> fails.
> 
> *** IR Dump After Module Verifier ***
> ; Function Attrs: nounwind
> define void @foo(i32 %lhs) #0 {
> entry:
> store i32 %lhs, i32* @g_bar, align 4, !tbaa !0
> ret void
> }
> Computing probabilities for entry
> 
> Initial selection DAG: BB#0 'foo:entry'
> SelectionDAG has 9 nodes:
> 0xbb93e8c: ch = EntryToken [ORD=1]
> 0xbbb8428: XXXi32 = Constant<0>
> 0xbb93e8c: <multiple use>
> 0xbb93e8c: <multiple use>
> 0xbbb8208: i64 = Register %vreg0 [ORD=1]
> 0xbbb8290: i64,ch = CopyFromReg 0xbb93e8c, 0xbbb8208 [ORD=1]
> 0xbbb8318: i32 = truncate 0xbbb8290 [ORD=1]
> 0xbbb83a0: XXXi32 = GlobalAddress<i32* @g_bar> 0 [ORD=1]
> 0xbbb84b0: XXXi32 = undef [ORD=1]
> 0xbbb8538: ch = store 0xbb93e8c, 0xbbb8318, 0xbbb83a0,
> 0xbbb84b0<ST4[@g_bar](tbaa=!"int")> [ORD=1]
> 0xbbb85c0: ch = PDISD::NODE_RET_FLAG 0xbbb8538
> -----
> 
> 
> 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

> 
> 
> 
> Greetings,
> 
> --
> Jeroen Dobbelaere
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory