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

Renato Golin renato.golin at linaro.org
Mon Sep 1 15:33:31 PDT 2014


Ah! Excellent idea! Thanks for looking at this, I'll keep an eye on the
bots.

Cheers,
Renato
On 1 Sep 2014 22:20, "David Majnemer" <david.majnemer at gmail.com> wrote:

> 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/fb2f6efd/attachment.html>


More information about the llvm-commits mailing list