In some (rare) cases, the context depth passed to a dynamic variable lookup can
be zero. In these cases, the fast path for the lookup (i.e. load from context or
global) can always be taken, as there is no need to search the current context.
However, with no slow path checks, the bytecode graph builder had a null
environment for the slow path, causing segfaults when this graph was built.
This patch adds a null check for the slow path environment, and skips building
the slow path if the environment is null.
BUG=chromium:652186
Review-Url: https://codereview.chromium.org/2385123002
Cr-Commit-Position: refs/heads/master@{#39949}
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}
- Changes tests to canonicalize FP slot/register moves, to simplify
testing any implementations that may fragment FP register moves.
- Adds code to generate correct ParallelMoves (e.g. no slot sources
of different reps overlapping.)
- Refactors test functions, so we can add manually generated tests
to current fuzzed tests.
- Adds SIMD operands, since these can be tested here now.
LOG=N
BUG=v8:4124
Review-Url: https://codereview.chromium.org/2365983002
Cr-Commit-Position: refs/heads/master@{#39943}
Added a test that Runtime.getProperties doesn't truncate Set and Map properties in [[Entries]] in internalProperties.
BUG=chromium:650729
R=dgozman@chromium.org
Review-Url: https://codereview.chromium.org/2376863002
Cr-Commit-Position: refs/heads/master@{#39940}
Recent changes to the wasm format prevent you from knowing
the function index of a direct call until you know how many
imports you have (the index spaces have been merged).
Asm.js validation can't know this until all callsites have been
visited if you want to avoid materializing the entire AST / parsing twice.
Instead, keep a list of fixups to perform for all direct callsites,
then update these with the imports count added when emitting the module.
BUG=v8:4203
R=aseemgarg@chromium.org,titzer@chromium.org
Review-Url: https://codereview.chromium.org/2384623003
Cr-Commit-Position: refs/heads/master@{#39937}
- Coalesced all anonymous namespaces into one, and moved it to the
top of the file, to match elsewhere in the v8 codebase.
- Deleted dead code.
- Moved functions that turned out to be local to wasm-module.cc to
the anonymous namespace.
BUG=
Review-Url: https://codereview.chromium.org/2384183002
Cr-Commit-Position: refs/heads/master@{#39936}
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}
Re-enable marking functions for optimized compilation on the next call
when using OSR. We would previously do this for all functions. However,
it only benefits functions marked for concurrent recompilation. These
would potentially run unoptimized again and be OSRed again.
In addition any function that already was optimized concurrently had
it's optimized code removed and would have been recompiled. Functions to
be baselined would skip that and possibly deopt.
BUG=chromium:651042
Review-Url: https://codereview.chromium.org/2391533002
Cr-Commit-Position: refs/heads/master@{#39934}
Hashmaps with a simple key equality method (comparing pointers) don't
need to waste cycles (and branches) comparing hash values, as the key
comparison is cheap.
This patch modifies the hashmap's MatchFun to take the hashes as well as
the keys, thus allowing the MatchFun to ignore the hashes. This allows
slightly cleaner generated code, especially when the MatchFun is
inlined.
BUG=
Review-Url: https://codereview.chromium.org/2381303002
Cr-Commit-Position: refs/heads/master@{#39932}
Calculate memory size from the available heap. This avoids
the bugs due to some numbers being stored as objects (by-ref)
and thus needing special handling when cloning.
This leaves all the rest of the numbers as read-only.
Further simplified by representing globals size as a Smi.
BUG=
Committed: https://crrev.com/7ced1bdc9df2315ccc07dd17c12736aebf40cb57
Review-Url: https://codereview.chromium.org/2381393002
Cr-Original-Commit-Position: refs/heads/master@{#39923}
Cr-Commit-Position: refs/heads/master@{#39925}
Reason for revert:
Failures on multiple bots (e.g. https://build.chromium.org/p/client.v8/builders/V8%20Mac%20GC%20Stress/builds/8887)
Original issue's description:
> [wasm] further simplification of WasmCompiledModule
>
> Calculate memory size from the available heap. This avoids
> the bugs due to some numbers being stored as objects (by-ref)
> and thus needing special handling when cloning.
>
> This leaves all the rest of the numbers as read-only.
>
> Further simplified by representing globals size as a Smi.
>
> BUG=
>
> Committed: https://crrev.com/7ced1bdc9df2315ccc07dd17c12736aebf40cb57
> Cr-Commit-Position: refs/heads/master@{#39923}
TBR=bradnelson@google.com,bradnelson@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/2385943002
Cr-Commit-Position: refs/heads/master@{#39924}
Calculate memory size from the available heap. This avoids
the bugs due to some numbers being stored as objects (by-ref)
and thus needing special handling when cloning.
This leaves all the rest of the numbers as read-only.
Further simplified by representing globals size as a Smi.
BUG=
Review-Url: https://codereview.chromium.org/2381393002
Cr-Commit-Position: refs/heads/master@{#39923}
Fixes the case when the 'imm' is in range [8000,ffff], as the specification
says the 'imm' is sign-extended before the comparsion, so the effective range
is [max_unsigned-7fff,max_unsigned].
TEST=mjsunit/generated-transition-stub@3b8ad45e
BUG=
Review-Url: https://codereview.chromium.org/2386673002
Cr-Commit-Position: refs/heads/master@{#39922}
This is to avoid a dereference of the unhandlified {this} reference
after handlified allocation functions have been called. Combining
handlified and unhandlified style is inherently unsafe.
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2380463006
Cr-Commit-Position: refs/heads/master@{#39921}
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}
This is essentially CL/2275293002, with the difference that the effect
dependencies are now updated correctly.
BUG=
Review-Url: https://codereview.chromium.org/2378773013
Cr-Commit-Position: refs/heads/master@{#39919}
This moves the Hydrogen-specific {is_tracking_positions} predicate which
also depends on the --hydrogen-track-positions flag into the Crankshaft
directory and removes it from the more general {CompilationInfo}.
R=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2377283002
Cr-Commit-Position: refs/heads/master@{#39913}
Port f84f45f9ca
Original commit message:
When zeroing a floating point stack slot, store the zero register directly,
rather than storing zero moved to an FP register.
BUG=
Review-Url: https://codereview.chromium.org/2364903002
Cr-Commit-Position: refs/heads/master@{#39906}
There are only a few occasions where we allocate a register in an outer
expression allocation scope, which makes the costly free-list approach
of the BytecodeRegisterAllocator unecessary. This CL replaces all
occurrences with moves to the accumulator and stores to a register
allocated in the correct scope. By doing this, we can simplify the
BytecodeRegisterAllocator to be a simple bump-pointer allocator
with registers released in the same order as allocated.
The following changes are also made:
- Make BytecodeRegisterOptimizer able to use registers which have been
unallocated, but not yet reused
- Remove RegisterExpressionResultScope and rename
AccumulatorExpressionResultScope to ValueExpressionResultScope
- Introduce RegisterList to represent consecutive register
allocations, and use this for operands to call bytecodes.
By avoiding the free-list handling, this gives another couple of
percent on CodeLoad.
BUG=v8:4280
Review-Url: https://codereview.chromium.org/2369873002
Cr-Commit-Position: refs/heads/master@{#39905}
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}
