Unlike other variable allocation logic, MODULE allocation does
not depend on resolution. So in order to give hole check elimination
(which runs during resolution) access to the information "is this
variable an import", simply allocate all modules variables prior
to resolution.

BUG=v8:1569

Review-Url: https://codereview.chromium.org/2458653002
Cr-Commit-Position: refs/heads/master@{#40621}

BUG=

Review-Url: https://codereview.chromium.org/2445993002
Cr-Commit-Position: refs/heads/master@{#40548}

Move hole check logic from full-codegen into scope analysis, and store the
"needs hole check" bit on VariableProxy. This makes it easy to re-use in
any backend: it will be trivial to extend the use of this logic in, e.g.,
full-codegen variable stores.

While changing the signatures of the variable loading/storing methods in
Ignition, I took the liberty of replacing the verb "Visit" with "Build", since these
are not part of AST visiting.

BUG=v8:5460

Review-Url: https://chromiumcodereview.appspot.com/2411873004
Cr-Commit-Position: refs/heads/master@{#40479}

BUG=v8:5209

Review-Url: https://codereview.chromium.org/2428533002
Cr-Commit-Position: refs/heads/master@{#40366}

BUG=v8:5209

Review-Url: https://codereview.chromium.org/2424693003
Cr-Commit-Position: refs/heads/master@{#40356}

BUG=

Review-Url: https://codereview.chromium.org/2425633002
Cr-Commit-Position: refs/heads/master@{#40349}

BUG=v8:5209

Review-Url: https://codereview.chromium.org/2423883002
Cr-Commit-Position: refs/heads/master@{#40343}

It belongs there more logically. In addition, this is a pre-step needed
for preparsing the parameters of a preparsed function.

In addition, move the "subtract rest parameter from arity" logic from
Parser to (Pre)?ParserFormalParameters.

BUG=v8:5515

Review-Url: https://codereview.chromium.org/2414003002
Cr-Commit-Position: refs/heads/master@{#40258}

Turn AllowsLazyParsingWithoutUnresolvedVariables into a whitelist stopping at the outer parsed context.

Any context outer to what we're parsing already has proper context allocation, so we don't need to check those scopes.

BUG=v8:5501

Review-Url: https://codereview.chromium.org/2417643003
Cr-Commit-Position: refs/heads/master@{#40256}

I don't see a reason why we can't benefit from preparsing such functions. We don't necessarily compile them, so fully parsing them when unnecessary is just additional overhead.

BUG=v8:5501

Review-Url: https://codereview.chromium.org/2413213002
Cr-Commit-Position: refs/heads/master@{#40248}

This is allocating registers in the function for all inner contexts that can be active in that function, so that nested blocks always have O(1) access to all outer contexts. However, currently it's always walking into nested functions, overallocating the number of registers, causing additional register pressure.

BUG=v8:5484

Review-Url: https://codereview.chromium.org/2408303003
Cr-Commit-Position: refs/heads/master@{#40214}

This is blocked on https://bugs.chromium.org/p/v8/issues/detail?id=5484

BUG=v8:5501

Review-Url: https://codereview.chromium.org/2405813002
Cr-Commit-Position: refs/heads/master@{#40167}

If an inner function only declares a variable but doesn't use it, Parser
and PreParser produced different unresolved variables, and that confused
the pessimistic context allocation.

This is continuation to https://codereview.chromium.org/2388183003/

This CL fixes more complicated declarations (which are not just one
identifier). For this, PreParser needs to accumulate identifiers used
in expressions.

In addition, this CL manifests FLAG_lazy_inner_functions in tests, so that
we get clusterfuzz coverage for it.

BUG=chromium:650969, v8:5501

Review-Url: https://codereview.chromium.org/2400613003
Cr-Commit-Position: refs/heads/master@{#40112}

For now keep the logic in compiler.cc and add a DCHECK that the scopes
and compiler.cc agree.

Use this knowledge to only created ScopeInfos for literals we'll
actually compile.

BUG=v8:5394,v8:5422
R=marja@chromium.org,verwaest@chromium.org

Review-Url: https://codereview.chromium.org/2399833002
Cr-Commit-Position: refs/heads/master@{#40074}

Review-Url: https://codereview.chromium.org/2399933005
Cr-Commit-Position: refs/heads/master@{#40066}

Now that the scope chain is deserialized directly from the chain of
{ScopeInfo} objects, it is no longer needed to provide a context. This
makes the {AllowsLazyCompilationWithoutContext} predicate coincide with
the more general {AllowsLazyCompilation}. Remove the former.

R=jochen@chromium.org

Review-Url: https://codereview.chromium.org/2399853002
Cr-Commit-Position: refs/heads/master@{#40042}

Clear also frees the memory, which isn't useful in the case of a zonelist. If we later want to use the list (e.g., because of aborting), that will cause additional allocations.

BUG=

Review-Url: https://codereview.chromium.org/2391953002
Cr-Commit-Position: refs/heads/master@{#39948}

If an inner function only declares a variable but doesn't use it, Parser
and PreParser produced different unresolved variables, and that confused
the pessimistic context allocation.

BUG=chromium:650969

Review-Url: https://codereview.chromium.org/2388183003
Cr-Commit-Position: refs/heads/master@{#39947}

Currently the parameter is first parsed as a reference, and then translated into a parameter. The reference stays around though, and gets resolved to the parameter. That automatically creates a use. Now that I drop all unresolved references when we abort preparsing, that also drops the unresolved reference.

Instead, mark the variable as used when its marked as forced context allocation. That's what happens in almost all other cases.

This raises the question: does it really make sense to parse parameters this ways? It seems pretty generic, but neither fast nor memory-efficient ... Did I misunderstand something?

Just land if you think the CL looks good as is.

BUG=chromium:651613

Review-Url: https://codereview.chromium.org/2386623002
Cr-Commit-Position: refs/heads/master@{#39935}

matching function, creates a hashmap the specialises the case of keys
that simply check pointer equality.

I measure an average ~1% improvement on Octane code-load.

Review-Url: https://codereview.chromium.org/2369963002
Cr-Commit-Position: refs/heads/master@{#39920}

It was meant to be recursive.

BUG=

Review-Url: https://codereview.chromium.org/2381283002
Cr-Commit-Position: refs/heads/master@{#39910}

Before evaluating a module, all variables declared at the top-level
in _any_ of the modules in the dependency graph must be initialized.
This is observable because a module A can access a variable imported
from module B (e.g. a function) at a point when module B's body hasn't
been evaluated yet.

We achieve this by implementing modules internally as generators with
two states (not initialized, initialized).

R=adamk@chromium.org
BUG=v8:1569
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_win_dbg

Committed: https://crrev.com/f4dfb6fbe1cdd9a0f287a1a9c496e1f69f6f5d20
Committed: https://crrev.com/8c52a411583e870bd5ed100864caa58f491c5d88
Review-Url: https://codereview.chromium.org/2375793002
Cr-Original-Original-Commit-Position: refs/heads/master@{#39871}
Cr-Original-Commit-Position: refs/heads/master@{#39892}
Cr-Commit-Position: refs/heads/master@{#39900}

Revert of Reland: [modules] Properly initialize declared variables. (patchset #6 id:100001 of https://codereview.chromium.org/2375793002/ )

Reason for revert:
Speculative revert for christmas tree

Original issue's description:
> Reland: [modules] Properly initialize declared variables.
>
> Before evaluating a module, all variables declared at the top-level
> in _any_ of the modules in the dependency graph must be initialized.
> This is observable because a module A can access a variable imported
> from module B (e.g. a function) at a point when module B's body hasn't
> been evaluated yet.
>
> We achieve this by implementing modules internally as generators with
> two states (not initialized, initialized).
>
> R=adamk@chromium.org
> BUG=v8:1569
> CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_win_dbg
>
> Committed: https://crrev.com/f4dfb6fbe1cdd9a0f287a1a9c496e1f69f6f5d20
> Committed: https://crrev.com/8c52a411583e870bd5ed100864caa58f491c5d88
> Cr-Original-Commit-Position: refs/heads/master@{#39871}
> Cr-Commit-Position: refs/heads/master@{#39892}

TBR=adamk@chromium.org,mstarzinger@chromium.org,machenbach@chromium.org,neis@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:1569

Review-Url: https://codereview.chromium.org/2387593002
Cr-Commit-Position: refs/heads/master@{#39896}

Before evaluating a module, all variables declared at the top-level
in _any_ of the modules in the dependency graph must be initialized.
This is observable because a module A can access a variable imported
from module B (e.g. a function) at a point when module B's body hasn't
been evaluated yet.

We achieve this by implementing modules internally as generators with
two states (not initialized, initialized).

R=adamk@chromium.org
BUG=v8:1569
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_win_dbg

Committed: https://crrev.com/f4dfb6fbe1cdd9a0f287a1a9c496e1f69f6f5d20
Review-Url: https://codereview.chromium.org/2375793002
Cr-Original-Commit-Position: refs/heads/master@{#39871}
Cr-Commit-Position: refs/heads/master@{#39892}

Revert of [modules] Properly initialize declared variables. (patchset #5 id:80001 of https://codereview.chromium.org/2375793002/ )

Reason for revert:
Suspect for causing win64 debug problems:
https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/12646

Original issue's description:
> [modules] Properly initialize declared variables.
>
> Before evaluating a module, all variables declared at the top-level
> in _any_ of the modules in the dependency graph must be initialized.
> This is observable because a module A can access a variable imported
> from module B (e.g. a function) at a point when module B's body hasn't
> been evaluated yet.
>
> We achieve this by implementing modules internally as generators with
> two states (not initialized, initialized).
>
> R=adamk@chromium.org
> BUG=v8:1569
>
> Committed: https://crrev.com/f4dfb6fbe1cdd9a0f287a1a9c496e1f69f6f5d20
> Cr-Commit-Position: refs/heads/master@{#39871}

TBR=adamk@chromium.org,mstarzinger@chromium.org,neis@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:1569

Review-Url: https://codereview.chromium.org/2379063002
Cr-Commit-Position: refs/heads/master@{#39873}

Before evaluating a module, all variables declared at the top-level
in _any_ of the modules in the dependency graph must be initialized.
This is observable because a module A can access a variable imported
from module B (e.g. a function) at a point when module B's body hasn't
been evaluated yet.

We achieve this by implementing modules internally as generators with
two states (not initialized, initialized).

R=adamk@chromium.org
BUG=v8:1569

Review-Url: https://codereview.chromium.org/2375793002
Cr-Commit-Position: refs/heads/master@{#39871}

BUG=chromium:651327

Review-Url: https://codereview.chromium.org/2380993003
Cr-Commit-Position: refs/heads/master@{#39864}

BUG=

Committed: https://crrev.com/ff8cfa9e5e8495165291ddf6e01dba3f8cb5a177
Review-Url: https://codereview.chromium.org/2374963002
Cr-Original-Commit-Position: refs/heads/master@{#39809}
Cr-Commit-Position: refs/heads/master@{#39834}

Previously we'd have a scope in the main zone, and another in the temp zone. Then we carefully copied back data to the main zone. This CL changes it so that the scope is just fixed up to only contain data from the main zone. That avoids additional copies and additional allocations; while not increasing the care that needs to be taken. This will also make it easier to abort preparsing while parsing using a temp zone.

BUG=

Committed: https://crrev.com/f41e7ebd62b32e861b6aa14ad8bfce3018d03c3c
Review-Url: https://codereview.chromium.org/2368313002
Cr-Original-Commit-Position: refs/heads/master@{#39800}
Cr-Commit-Position: refs/heads/master@{#39828}

Revert of Don't use different function scopes when parsing with temp zones (patchset #11 id:200001 of https://codereview.chromium.org/2368313002/ )

Reason for revert:
Revert due to asm.js slowdown

Original issue's description:
> Don't use different function scopes when parsing with temp zones
>
> Previously we'd have a scope in the main zone, and another in the temp zone. Then we carefully copied back data to the main zone. This CL changes it so that the scope is just fixed up to only contain data from the main zone. That avoids additional copies and additional allocations; while not increasing the care that needs to be taken. This will also make it easier to abort preparsing while parsing using a temp zone.
>
> BUG=
>
> Committed: https://crrev.com/f41e7ebd62b32e861b6aa14ad8bfce3018d03c3c
> Cr-Commit-Position: refs/heads/master@{#39800}

TBR=marja@chromium.org,adamk@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

Review-Url: https://codereview.chromium.org/2379533003
Cr-Commit-Position: refs/heads/master@{#39821}

Revert of Preparse top-level functions in discardable zones (patchset #2 id:20001 of https://codereview.chromium.org/2374963002/ )

Reason for revert:
Needed to revert https://codereview.chromium.org/2368313002 which slows down asm.js code

Original issue's description:
> Preparse top-level functions in discardable zones
>
> BUG=
>
> Committed: https://crrev.com/ff8cfa9e5e8495165291ddf6e01dba3f8cb5a177
> Cr-Commit-Position: refs/heads/master@{#39809}

TBR=marja@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

Review-Url: https://codereview.chromium.org/2375013002
Cr-Commit-Position: refs/heads/master@{#39815}

BUG=

Review-Url: https://codereview.chromium.org/2374963002
Cr-Commit-Position: refs/heads/master@{#39809}

Previously we'd have a scope in the main zone, and another in the temp zone. Then we carefully copied back data to the main zone. This CL changes it so that the scope is just fixed up to only contain data from the main zone. That avoids additional copies and additional allocations; while not increasing the care that needs to be taken. This will also make it easier to abort preparsing while parsing using a temp zone.

BUG=

Review-Url: https://codereview.chromium.org/2368313002
Cr-Commit-Position: refs/heads/master@{#39800}

BUG=

Review-Url: https://codereview.chromium.org/2372703004
Cr-Commit-Position: refs/heads/master@{#39769}

Reland of Preparse inner functions (new try) (patchset #1 id:1 of https://codereview.chromium.org/2373443003/ )

Reason for revert:
Stability thief found, relanding speculative reverts.

Original issue's description:
> Revert of Preparse inner functions (new try) (patchset #21 id:420001 of https://codereview.chromium.org/2352593002/ )
>
> Reason for revert:
> We currently have some stability issues on Canary. Let's reland this after we verified that we "fixed" Canary again.
>
> Original issue's description:
> > Preparse inner functions (new try)
> >
> > This is an overly pessimistic approach where PreParser only keeps
> > track of unresolved variables, but doesn't declare anything. This
> > will result in context-allocating variables in the outer function
> > unnecessarily, if the variable names clash with variable names
> > used by the inner function (even if the variables are not the
> > same). However, we have been unable to prove that this approach
> > wouldn't be good enough for the practical purposes.
> >
> > Fixes after the previous try ( https://codereview.chromium.org/2322243002/ ):
> > Keep the context-allocation decision stable when compiling fully eagerly.
> >
> > Tests which exercise this functionality:
> > mjsunit/fixed-context-shapes-when-recompiling.js
> >
> > Design document (chromium):
> >
> > https://docs.google.com/a/chromium.org/document/d/1rRv5JJZ0JpOZAZN2CSUwZPFJiBAdRnTiSYhazseNHFg/edit?usp=sharing
> >
> > BUG=
> >
> > Committed: https://crrev.com/7c73cf32c60484cdf37c84f1d61b4640e87068d7
> > Cr-Commit-Position: refs/heads/master@{#39719}
>
> TBR=verwaest@chromium.org,adamk@chromium.org,marja@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=
>
> Committed: https://crrev.com/1e6296b2a7cfc307fd9e722e619f42965da4a267
> Cr-Commit-Position: refs/heads/master@{#39730}

TBR=verwaest@chromium.org,adamk@chromium.org,marja@chromium.org,hablich@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

Review-Url: https://codereview.chromium.org/2377513006
Cr-Commit-Position: refs/heads/master@{#39755}

Revert of Preparse inner functions (new try) (patchset #21 id:420001 of https://codereview.chromium.org/2352593002/ )

Reason for revert:
We currently have some stability issues on Canary. Let's reland this after we verified that we "fixed" Canary again.

Original issue's description:
> Preparse inner functions (new try)
>
> This is an overly pessimistic approach where PreParser only keeps
> track of unresolved variables, but doesn't declare anything. This
> will result in context-allocating variables in the outer function
> unnecessarily, if the variable names clash with variable names
> used by the inner function (even if the variables are not the
> same). However, we have been unable to prove that this approach
> wouldn't be good enough for the practical purposes.
>
> Fixes after the previous try ( https://codereview.chromium.org/2322243002/ ):
> Keep the context-allocation decision stable when compiling fully eagerly.
>
> Tests which exercise this functionality:
> mjsunit/fixed-context-shapes-when-recompiling.js
>
> Design document (chromium):
>
> https://docs.google.com/a/chromium.org/document/d/1rRv5JJZ0JpOZAZN2CSUwZPFJiBAdRnTiSYhazseNHFg/edit?usp=sharing
>
> BUG=
>
> Committed: https://crrev.com/7c73cf32c60484cdf37c84f1d61b4640e87068d7
> Cr-Commit-Position: refs/heads/master@{#39719}

TBR=verwaest@chromium.org,adamk@chromium.org,marja@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

Review-Url: https://codereview.chromium.org/2373443003
Cr-Commit-Position: refs/heads/master@{#39730}

This is an overly pessimistic approach where PreParser only keeps
track of unresolved variables, but doesn't declare anything. This
will result in context-allocating variables in the outer function
unnecessarily, if the variable names clash with variable names
used by the inner function (even if the variables are not the
same). However, we have been unable to prove that this approach
wouldn't be good enough for the practical purposes.

Fixes after the previous try ( https://codereview.chromium.org/2322243002/ ):
Keep the context-allocation decision stable when compiling fully eagerly.

Tests which exercise this functionality:
mjsunit/fixed-context-shapes-when-recompiling.js

Design document (chromium):

https://docs.google.com/a/chromium.org/document/d/1rRv5JJZ0JpOZAZN2CSUwZPFJiBAdRnTiSYhazseNHFg/edit?usp=sharing

BUG=

Review-Url: https://codereview.chromium.org/2352593002
Cr-Commit-Position: refs/heads/master@{#39719}

There's no reason (anymore) to have empty imports in special_imports.  Remove
them from there and rename special_imports to namespace_imports to be more
precise.

R=adamk@chromium.org
BUG=v8:1569

Review-Url: https://codereview.chromium.org/2368613002
Cr-Commit-Position: refs/heads/master@{#39693}

Remove ARGUMENTS_VARIABLE and fix crankshaft to properly detect the arguments object and keep it alive when inlining .apply

BUG=

Review-Url: https://codereview.chromium.org/2367483003
Cr-Commit-Position: refs/heads/master@{#39670}

BUG=chromium:649067

Review-Url: https://codereview.chromium.org/2362463003
Cr-Commit-Position: refs/heads/master@{#39642}