1070948 - Assertion failure: i != graph.poEnd() (Reached the end of the graph while searching for the loop header), at jit/IonAnalysis.cpp:3181

Status: RESOLVED FIXED

(Core :: JavaScript Engine: JIT, defect)

Description

[Christian Holler (:decoder)]

The following testcase asserts on mozilla-central revision 5bd6e09f074e (run with --no-threads --fuzzing-safe --ion-eager):


var generics = {
  String: []
};
for (var c in generics) {
  try {
    throw new Error();
  } catch (e) {} 
  while (--noop != 0);
}

Comment 1

[Christian Holler (:decoder)]

JSBugMon: Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/8f27a48a25d5
user:        Dan Gohman
date:        Wed Sep 17 10:27:25 2014 -0700
summary:     Bug 1029830 - IonMonkey: GVN: Replace UCE with GVN r=nbp

This iteration took 341.162 seconds to run.

Comment 2

[Hannes Verschore [:h4writer]]

Dan, can you have a look? Bisect points to UCE/GVN unification. I know you fixed some similar issues in the last days. Can you confirm this is fixed by those? Or else have a look what is going wrong here?

Comment 3

[Dan Gohman [:sunfish]]

Attachment: broken-loops.patch

With GVN now folding MTest to MGoto, it has opened up the possibility that such folding could remove the only path from a loop header to its backedge. In such cases, the loop becomes degenerate, and optimizations like LICM are no longer useful. Detect such loops, and skip loop-oriented optimizations on them.

Comment 4

[Nicolas B. Pierron [:nbp] {away}]

Comment on attachment 8496191 [details] [diff] [review]
broken-loops.patch

Review of attachment 8496191 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/jit/IonAnalysis.cpp
@@ +3239,5 @@
>      }
> +
> +    // If there's no path connecting the header to the backedge, then this isn't
> +    // actually a loop. This can happen when the code starts with a loop but GVN
> +    // folds some branches away.

I am not sure to understand what you mean by "fold - away"?

Comment 5

[Nicolas B. Pierron [:nbp] {away}]

Comment on attachment 8496191 [details] [diff] [review]
broken-loops.patch

Review of attachment 8496191 [details] [diff] [review]:
-----------------------------------------------------------------

Ask again for review after answering the previous question.

Comment 6

[Christian Holler (:decoder)]

Attachment: [crash-signature] Machine-readable crash signature

Comment 7

[Dan Gohman [:sunfish]]

Comment on attachment 8496191 [details] [diff] [review]
broken-loops.patch

Review of attachment 8496191 [details] [diff] [review]:
-----------------------------------------------------------------

(In reply to Nicolas B. Pierron [:nbp] from comment #4)
> Comment on attachment 8496191 [details] [diff] [review]
> broken-loops.patch
> 
> Review of attachment 8496191 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: js/src/jit/IonAnalysis.cpp
> @@ +3239,5 @@
> >      }
> > +
> > +    // If there's no path connecting the header to the backedge, then this isn't
> > +    // actually a loop. This can happen when the code starts with a loop but GVN
> > +    // folds some branches away.
> 
> I am not sure to understand what you mean by "fold - away"?

I meant folding an MTest into an MGoto. In the testcase, there's an MTest with a constant condition. GVN folds it to an MGoto to one of the successors, one that happens to be outside the loop, so that there's no longer any edge to a block that's inside the loop.

Comment 8

[Dan Gohman [:sunfish]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c3bb5abdd01e

Comment 9

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/c3bb5abdd01e