WIP to fix code-load regression

WIP to fix code-load regression

Regression was here: https://chromium.googlesource.com/v8/v8/+/e73594c7fb3e6b5834b7ddfe78727fb994bab25f

R=dslomov@chromium.org
LOG=N
BUG=

[wingo, 2015-05-19 15:05:34]

A WIP to fix the code-load regression.  Before the offending patch, a code-load
run locally took 903M instructions with ia32.release, after about 924M
instructions, which matches the measured regression.  Simply commenting out the
nested classifier in ParseAssignmentExpression removes the regression.  However
it is doing a thing for us :)  so it would be nice to keep it.

This patch doesn't fix the problem however, instead it just golfs the count down
to 918M instructions.  Copying around these error is silly anyway; there should
be a way to avoid doing that.  Ideas welcome.

[wingo, 2015-05-19 15:15:41]

Another thing that could work would be to write errors into a buffer instead,
and the buffer doesn't get copied.  An ExpressionClassifier would become a
pointer to the start of the buffer, along with a mask of invalid-production
errors seen since the start of the buffer.  I guess you'd allocate the buffer in
the zone.  This could also allow for varying sizes of errors, if that mattered.

[wingo, 2015-05-19 16:20:58]

On 2015/05/19 15:15:41, wingo wrote:
> Another thing that could work would be to write errors into a buffer instead,
> and the buffer doesn't get copied.  An ExpressionClassifier would become a
> pointer to the start of the buffer, along with a mask of invalid-production
> errors seen since the start of the buffer.  I guess you'd allocate the buffer
in
> the zone.  This could also allow for varying sizes of errors, if that
mattered.

I tried this and it didn't help.  On the other hand, adding a simple "if (errors
== 0) return" shortcut to Accumulate() golfed me down to 910M instructions,
which is getting there.

[wingo, 2015-05-19 16:55:33]

On 2015/05/19 16:20:58, wingo wrote:
> On 2015/05/19 15:15:41, wingo wrote:
> > Another thing that could work would be to write errors into a buffer
instead,
> > and the buffer doesn't get copied.  An ExpressionClassifier would become a
> > pointer to the start of the buffer, along with a mask of invalid-production
> > errors seen since the start of the buffer.  I guess you'd allocate the
buffer
> in
> > the zone.  This could also allow for varying sizes of errors, if that
> mattered.
> 
> I tried this and it didn't help.  On the other hand, adding a simple "if
(errors
> == 0) return" shortcut to Accumulate() golfed me down to 910M instructions,
> which is getting there.

It turns out that this bailout was too early, as it wasn't propagating the
ArrowFormalParametersProduction bit; adding that back in got us back to 915M. 
Irritating.

Regarding buffers: there should be some way to use a buffer as a stack.  Like,
whenever you go to assert that something is an expression (or some other
terminal production), you can truncate the buffer back to where it was when the
ExpressionClassifier was created.  If you need to signal an error, it's probably
acceptable to do linear search within some range of the buffer; you'd have to
record the pushes and pops of when you make new ExpressionClassifiers though. 
Anyway that might allow ExpressionClassifier itself to not have to hold onto
individual error locations, and just be a buffer offset + bitmask.

[wingo, 2015-05-20 07:28:53]

> Regarding buffers: there should be some way to use a buffer as a stack.  Like,
> whenever you go to assert that something is an expression (or some other
> terminal production), you can truncate the buffer back to where it was when
the
> ExpressionClassifier was created.  If you need to signal an error, it's
probably
> acceptable to do linear search within some range of the buffer; you'd have to
> record the pushes and pops of when you make new ExpressionClassifiers though. 
> Anyway that might allow ExpressionClassifier itself to not have to hold onto
> individual error locations, and just be a buffer offset + bitmask.

I gave this a go, but it's just as slow as "master".  Patch here:

 
https://github.com/andywingo/v8/commit/545d33648de98998c9d0d1ac70df4620d8d03ba5

I don't really understand why it's just as slow (924M); it should be faster!

[wingo, 2015-06-09 17:31:52]

Closing this one; I couldn't get a buffer-based thing to go faster.  Oh well :)