[llvm] r216523 - InstCombine: Optimize GEP's involving ptrtoint better
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
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>
>> On Mon, Sep 1, 2014 at 2:09 PM, Renato Golin <renato.golin at linaro.org>
>>> 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.
>>> 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.
>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits