[PATCH] Don't constant fold bitcast/ptrtoint/inttoptr combinations without datalayout

[Eli Friedman]

On Tue, Jul 16, 2013 at 5:13 PM, Matt Arsenault <arsenm2 at gmail.com> wrote:
>
> On Jul 16, 2013, at 16:41 , Eli Friedman <eli.friedman at gmail.com> wrote:
>
>> On Tue, Jul 16, 2013 at 11:57 AM, Matt Arsenault
>> <Matthew.Arsenault at amd.com> wrote:
>>> Hi eli.friedman,
>>>
>>> This is necessary to check for constantexpr inttoptr -> illegal bitcasts required for http://llvm-reviews.chandlerc.com/D1083
>>>
>>> For some reason, constant folding happens before the verifier is reached, so my tests for rejecting those illegal bitcasts in this case can't work.
>>>
>>> This change also causes a test to hit the bug that is fixed by http://llvm-reviews.chandlerc.com/D1114
>>>
>>> As it is right now, this introduces one inline cost test failure, which I believe will be fixed by another larger patch I have that I was going to submit later that adds the address space support there.
>>
>> Which test is this?  It's likely to be a bug in the test if it's
>> depending on our behavior here.
>
> Transforms/Inline/inline_constprop.ll
>
> It expects callee5 to be inlined, but with this patch it isn't anymore.

Oh... I just realized what this patch is doing.  Sorry, I was somehow
confused before.

     case 11:
       // bitcast followed by ptrtoint is allowed as long as the bitcast
       // is a pointer to pointer cast.
-      if (SrcTy->isPointerTy() && MidTy->isPointerTy())
+      if (SrcTy->isPointerTy() &&
+          MidTy->isPointerTy() &&
+          SrcIntPtrTy &&
+          DstIntPtrTy &&
+          SrcIntPtrTy->getScalarSizeInBits() ==
+          DstIntPtrTy->getScalarSizeInBits())
         return secondOp;
       return 0;

If SrcTy and MidTy have the same address-space, we know they have the
same size; shouldn't we constant-fold even if we don't know what that
size is?

-Eli