[llvm] r216523 - InstCombine: Optimize GEP's involving ptrtointbetter

[Chandler Carruth]

On Thu, Aug 28, 2014 at 3:52 PM, David Majnemer <david.majnemer at gmail.com>
wrote:

> On Thu, Aug 28, 2014 at 3:44 PM, Renato Golin <renato.golin at linaro.org>
> wrote:
>
>> So, the problem is indeed the transformation, as it changes:
>>
>>    0x0002d6c8 <+276>: mov r4, r7
>>    0x0002d6cc <+280>: ldr r0, [r4, #4]
>>    0x0002d6d0 <+284>: ldr r1, [r8]
>>    0x0002d6d4 <+288>: rsb r0, r0, #0
>>    0x0002d6d8 <+292>: asr r0, r0, r6
>>    0x0002d6dc <+296>: ldr r0, [r1, r0, lsl #2]
>>    0x0002d6e0 <+300>: ldr r1, [r5]
>>    0x0002d6e4 <+304>: ldr r0, [r0]
>>
>> into
>>
>>    0x0002d61c <+264>: mov r4, r5
>>    0x0002d620 <+268>: ldr r0, [r4, #4]
>>    0x0002d624 <+272>: ldr r1, [r8]
>>    0x0002d628 <+276>: ldr r0, [r1, -r0]
>>    0x0002d62c <+280>: ldr r1, [r7]
>>    0x0002d630 <+284>: ldr r0, [r0]
>>
>> Note the -r0 versus (^r0>>r6)<<2, only that r0 is already negative
>> when it gets to the load with offset. That's from the line:
>>
>>   fputs(S->name, stdout)
>>
>> with r0 as S->name, and r0 being 0x0 at the final load.
>>
>> Given that this transformation has also broken MIPS bots, I think we
>> should revert it for now until better investigations are done.
>>
>
> I'd be all for reverting it if we had LLVM IR that we can commit with the
> revert which shows the problem.
>

I don't think its unreasonable to revert while we're getting the IR...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140828/a7d43d28/attachment.html>