[llvm] r295378 - [LSR] Prevent formula with SCEVAddRecExpr type of Reg from Sibling loops

[Wei Mi via llvm-commits]

On Wed, Feb 22, 2017 at 5:15 PM, Davide Italiano <davide at freebsd.org> wrote:

> On Wed, Feb 22, 2017 at 5:03 PM, Wei Mi <wmi at google.com> wrote:
> >
> >
> > On Wed, Feb 22, 2017 at 4:08 PM, Wei Mi <wmi at google.com> wrote:
> >>
> >>
> >>
> >> On Wed, Feb 22, 2017 at 3:46 PM, Davide Italiano <davide at freebsd.org>
> >> wrote:
> >>>
> >>> On Thu, Feb 16, 2017 at 1:27 PM, Wei Mi via llvm-commits
> >>> <llvm-commits at lists.llvm.org> wrote:
> >>> > Author: wmi
> >>> > Date: Thu Feb 16 15:27:31 2017
> >>> > New Revision: 295378
> >>> >
> >>> > URL: http://llvm.org/viewvc/llvm-project?rev=295378&view=rev
> >>> > Log:
> >>> > [LSR] Prevent formula with SCEVAddRecExpr type of Reg from Sibling
> >>> > loops
> >>> >
> >>>
> >>> Sorry if I'm late, but our downstream branch was a little bit behind.
> >>> With this test LTO time of some of our internal codebases skyrockets.
> >>> running `llc` on the test attached takes ~7 seconds with the change
> >>> reverted and I had to kill it after 10 minutes with the change in. Can
> >>> you please take a look, and see if you can fix this easily (or
> >>> revert?) I'd like to get our bots green again.
> >>>
> >>
> >> Sorry to break your bot. I can reproduce the problem and am looking at
> it.
> >> Thanks for the testcase.
> >>
> >> Wei.
> >
> >
> > Hi Davide,
> >
> > I found the problem was there for a long time (I reproduce the same
> problem
> > since r290782. I cannot try earlier versions because they cannot digest
> the
> > IR). rL294814 just hided the problem and rL295378 exposed the problem
> again.
> >
>
> This is unfortunate, maybe it's time to bite the bullet and
> analyze/fix the underlying problem?
>
>
Filed a bug here: https://bugs.llvm.org/show_bug.cgi?id=32043
I will take a deeper look into it.


> > Is this the first time you see the problem? I am curious why it doesn't
> > break the bot before.
> >
>
> This is a bot I just set up recently (mid January, to test NewGVN with
> some of our internal codebases).
> r290782 (by Dan, cc:ed) is unlikely to be the culprit, FWIW.
>
>
I am not saying r290781 passed and r290782 failed. I just randomly picked
r290782 and reproduced the same problem. Then I randomly picked an older
version but that version couldn't process the IR. I am pretty sure r290782
is not the culprit.

Wei.


> --
> Davide
>
> "There are no solved problems; there are only problems that are more
> or less solved" -- Henri Poincare
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170222/eff9887a/attachment.html>