llvm dev - Apr 2014 - [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 ?

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

----- 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

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 :(.

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