<div dir="ltr">Hi Hal,<br><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Apr 4, 2014 at 1:22 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">[..]</blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.<br>
<span class=""><font color="#888888"><br>
 -Hal<br>
</font></span><div class=""><div class="h5"><br></div></div></blockquote></div><br></div><div class="gmail_extra">I actually missed implementing this one. But, depending on the testcase that I use,<br></div><div class="gmail_extra">
implementing it has no or worse effect:<br><br></div><div class="gmail_extra">I now get assertion errors complaining of different value sizes, coming from the<br></div><div class="gmail_extra">difference between the datalayout (ptrsize:i32) and the pointerty (size overruled to i64).<br>
</div><div class="gmail_extra">in SelectionDag::InferPtrAlignment.<br></div><div class="gmail_extra">I also found out the this method is not called at all (for my (failing) tests) during the initial selection dag buildup.<br>
<br></div><div class="gmail_extra">Note:<br>-  most of my testing is done on llvm-3.3, but I verified that the same issues are there for llvm-3.4<br></div><div class="gmail_extra">- I did implement:  <br>    virtual MVT getScalarShiftAmountTy(EVT LHSTy) const { return MVT::i64; }<br>
</div><div class="gmail_extra">  although I have no good idea why the default for that is mapped to the pointer type...  <br></div><div class="gmail_extra"><br>In the following sample:<br>- if full 64bit pointers are used, XXXi32 will be 'i64' and everything legalizes/compiles fine<br>
- if 32bit pointers are used, XXXi32 will be 'i32' and legalization fails.<br> <br>*** IR Dump After Module Verifier ***<br>; Function Attrs: nounwind<br>define void @foo(i32 %lhs) #0 {<br>entry:<br>  store i32 %lhs, i32* @g_bar, align 4, !tbaa !0<br>
  ret void<br>}<br>Computing probabilities for entry<br><br>Initial selection DAG: BB#0 'foo:entry'<br>SelectionDAG has 9 nodes:<br>  0xbb93e8c: ch = EntryToken [ORD=1]<br>  0xbbb8428: XXXi32 = Constant<0><br>
      0xbb93e8c: <multiple use><br>          0xbb93e8c: <multiple use><br>          0xbbb8208: i64 = Register %vreg0 [ORD=1]<br>        0xbbb8290: i64,ch = CopyFromReg 0xbb93e8c, 0xbbb8208 [ORD=1]<br>      0xbbb8318: i32 = truncate 0xbbb8290 [ORD=1]<br>
      0xbbb83a0: XXXi32 = GlobalAddress<i32* @g_bar> 0 [ORD=1]<br>      0xbbb84b0: XXXi32 = undef [ORD=1]<br>    0xbbb8538: ch = store 0xbb93e8c, 0xbbb8318, 0xbbb83a0, 0xbbb84b0<ST4[@g_bar](tbaa=!"int")> [ORD=1]<br>
  0xbbb85c0: ch = PDISD::NODE_RET_FLAG 0xbbb8538<br>-----<br><br></div><div class="gmail_extra">Is this difference indeed what we would need to expect at this level ?<br>- should we learn the selection dag creator to use the first larger or equal valid type (i64) here ?<br>
</div><div class="gmail_extra">- or should we make sure that the legalization phase accepts the mix of types that is produced in that case ?<br></div><div class="gmail_extra"><br clear="all"></div><div class="gmail_extra">
Greetings,<br></div><div class="gmail_extra">-- <br>Jeroen Dobbelaere<br>
</div></div></div>