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

[Jeroen Dobbelaere]

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>