[llvm] r216523 - InstCombine: Optimize GEP's involving ptrtoint better
David Majnemer
david.majnemer at gmail.com
Mon Sep 1 14:20:42 PDT 2014
On Mon, Sep 1, 2014 at 2:16 PM, David Majnemer <david.majnemer at gmail.com>
wrote:
> On Mon, Sep 1, 2014 at 2:09 PM, Renato Golin <renato.golin at linaro.org>
> wrote:
>
>> On 1 September 2014 20:14, Doug Gilmore <Doug.Gilmore at imgtec.com> wrote:
>> > Unfortunately it is also just in SPASS, so it probably doesn't provide
>> much help in
>> > producing an isolated test case.
>>
>> Shame.
>>
>> On my side, the problem seems to be simplifying a read from a constant
>> pool or global area to an indirect register read, is that the same in
>> your case? There's a lot of inlining going on in that area, making it
>> harder to guess the pattern. What I did was to compile with the patch
>> in on -O2, and with the patch reverted on -O2 and compare the debug
>> disassembly just before the exception happens.
>>
>> I don't think that's the *only* place that optimisation changed the
>> whole test-suite, so I believe it's just a corner case that both MIPS
>> and ARM have in common that probably x86 doesn't. If your problem
>> breaks on the same place, at least we know that's true.
>>
>> Nuno,
>>
>> You seem to have an idea of what could break the assumption, maybe you
>> can try a few cases on opt if the value of the pointer comes from a
>> global offset or a local constant?
>>
>
> I've figured out the problem, a fix is on it's way.
>
> The problem wasn't the math behind the transform; there was a bug in the
> way I wrote the pattern matching.
>
This should be fixed in r216890. Thanks everyone for your help in tracking
this down!
I had trouble reproducing it until I finally tried a 32-bit x86 build of
SPASS...
>
>
>>
>> cheers,
>> --renato
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140901/9b2300de/attachment.html>
More information about the llvm-commits
mailing list