Both --harmony-object-values-entries and --harmony-object-own-property-descriptors
are on by default in v8 5.4, which has now shipped to
stable as Chrome 54.
R=caitp@igalia.com
Review-Url: https://codereview.chromium.org/2464733003
Cr-Commit-Position: refs/heads/master@{#40683}
This function is implemented in other JavaScript shells
BUG=None
R=titzer
Review-Url: https://codereview.chromium.org/2458963003
Cr-Commit-Position: refs/heads/master@{#40677}
This exposes a couple of broken tests that used to silently throw within
the listener. Mark these as failing for now
BUG=v8:5330, v8:5581
Review-Url: https://codereview.chromium.org/2460833002
Cr-Commit-Position: refs/heads/master@{#40672}
This enables Ignition unconditionally for all code that is destined for
optimization with TurboFan. This ensures all optimization attempts will
go through the BytecodeGraphBuilder and that the AstGraphBuilder pipe is
dried out in practice.
patch from issue 2427953002 at patchset 120001 (http://crrev.com/2427953002#ps120001)
R=mvstanton@chromium.org,rmcilroy@chromium.org
Review-Url: https://codereview.chromium.org/2453973004
Cr-Commit-Position: refs/heads/master@{#40663}
Conflicting type feedback on Load/StoreICs can lead to out-of-bounds
field access, which is essentially dead code, but EscapeAnalysis was
confused about those. For now, mark the objects as escaping in these
cases, middle-term we want to deal better with this kind of compile-
time known dead code.
BUG=chromium:658185,v8:4586
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2459273002
Cr-Commit-Position: refs/heads/master@{#40662}
This flag is on by default for now. Whenever heuristics in the compiler
pipeline decide to use Ignition+TurboFan, then {BytecodeGraphBuilder} is
active. Removing the flag reduces maintenance overhead.
R=mvstanton@chromium.org
Review-Url: https://codereview.chromium.org/2437103002
Cr-Commit-Position: refs/heads/master@{#40639}
This CL adds simple implementation of break and stepping-related functionality
as required by the debug-step.js test. This includes
* stepOver, stepInto, stepOut
* setBreakPoint
* clearBreakPoint
* evaluate
Some of these, e.g. setBreakPoint are not fully implemented for all cases but
only for the ones we need right now.
One interesting result of this is that using the inspector protocol is roughly
14x slower for debug-step.js (14s instead of 0.5s). One cause of this seems to
be iteration over all object properties in toProtocolValue, which is used to
serialize JS objects before being sent over the wire (e.g. FrameMirrors). This
is something that should be fixed at some point. In the meantime, the test now
runs 100 instead of 1000 iterations.
BUG=v8:5530
Review-Url: https://codereview.chromium.org/2447073007
Cr-Commit-Position: refs/heads/master@{#40636}
The assumptions that OSR code is installed on {JSFunction} objects no
longer holds with TurboFan and hence {assertOptimized} can report a
different result dependeing on how OSR code is treated. This is working
as intended.
R=mythria@chromium.org
Review-Url: https://codereview.chromium.org/2453313002
Cr-Commit-Position: refs/heads/master@{#40624}
For inputs to truncating binary operations like <<, | or >>>, support
all Oddballs not just undefined, true and false. This unifies treatment
of these truncations in Crankshaft and TurboFan, and is very easy
nowadays, since the memory layout of Oddball and HeapNumber is
compatible.
R=yangguo@chromium.org
BUG=v8:5400
Review-Url: https://codereview.chromium.org/2452193003
Cr-Commit-Position: refs/heads/master@{#40608}
For instance, when an import cannot be resolved, actually
point at the corresponding import statement.
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2451153002
Cr-Commit-Position: refs/heads/master@{#40594}
For global object property cells, we did not check that the map on the
previous object is still the same for which we actually optimized. So
the optimized code was not in sync with the actual state of the property
cell. When loading from such a global object property cell, Crankshaft
optimizes away any map checks (based on the stable map assumption),
leading to arbitrary memory access in the worst case.
TurboFan has the same bug for stores, but is safe on loads because we
do appropriate map checks there. However mixing TurboFan and Crankshaft
still exposes the bug.
R=yangguo@chromium.org
BUG=chromium:659475
Review-Url: https://codereview.chromium.org/2444233004
Cr-Commit-Position: refs/heads/master@{#40592}
The TurboFan backends currently don't support tail-calls to CPP builtins
because the semantics of kJavaScriptCallArgCountRegister has different
semantics for stub call descriptors versus JavaScript call descriptors.
This is actually a short-coming of the backends and follow-up work will
make the backends more robust in that regard to fail hard on unsupported
constructs like that. This just disables the lowering creating such a
tail-call.
R=bmeurer@chromium.org
BUG=chromium:658691
TEST=mjsunit/regress/regress-crbug-658691
Review-Url: https://codereview.chromium.org/2447383002
Cr-Commit-Position: refs/heads/master@{#40590}
Reason for revert:
Breaks tree: http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/8789
Original issue's description:
> [compiler] Properly validate stable map assumption for globals.
>
> For global object property cells, we did not check that the map on the
> previous object is still the same for which we actually optimized. So
> the optimized code was not in sync with the actual state of the property
> cell. When loading from such a global object property cell, Crankshaft
> optimizes away any map checks (based on the stable map assumption),
> leading to arbitrary memory access in the worst case.
>
> TurboFan has the same bug for stores, but is safe on loads because we
> do appropriate map checks there. However mixing TurboFan and Crankshaft
> still exposes the bug.
>
> R=yangguo@chromium.org
> BUG=chromium:659475
TBR=yangguo@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:659475
Review-Url: https://codereview.chromium.org/2454513003
Cr-Commit-Position: refs/heads/master@{#40582}
Native setters (see AccessorInfo in accessors.h) didn't have the ability
to return a result value. As a consequence of this, for instance, Reflect.set
on the length property of arrays had the wrong behavior:
var y = [];
Object.defineProperty(y, 0, {value: 42, configurable: false})
Reflect.set(y, 'length', 0)
The Reflect.set call used to return true. Now it returns false as
required by the spec.
BUG=v8:5401
Review-Url: https://codereview.chromium.org/2397603003
Cr-Commit-Position: refs/heads/master@{#40579}
For global object property cells, we did not check that the map on the
previous object is still the same for which we actually optimized. So
the optimized code was not in sync with the actual state of the property
cell. When loading from such a global object property cell, Crankshaft
optimizes away any map checks (based on the stable map assumption),
leading to arbitrary memory access in the worst case.
TurboFan has the same bug for stores, but is safe on loads because we
do appropriate map checks there. However mixing TurboFan and Crankshaft
still exposes the bug.
R=yangguo@chromium.org
BUG=chromium:659475
Review-Url: https://codereview.chromium.org/2444233004
Cr-Commit-Position: refs/heads/master@{#40578}
Fix failing assertions in the CodeStubAssembler that cause Object.create(null,
global) fail.
Drive-by-fix: convert some Assert to CSA_ASSERT.
BUG=chromium:657692
Review-Url: https://codereview.chromium.org/2446203003
Cr-Commit-Position: refs/heads/master@{#40576}
This brings the BytecodeGenerator in line with FullCodeGenerator, now that
more requests for hole checks are flowing through BuildVariableAssignment.
BUG=chromium:658528
Review-Url: https://codereview.chromium.org/2447783002
Cr-Commit-Position: refs/heads/master@{#40557}
Object.create(null) is most likely to be used for dictionary-like objects.
Hence it would be beneficial to directly create a slow-mode object and avoid
additional overhead later-on.
BUG=
Review-Url: https://codereview.chromium.org/2430273007
Cr-Commit-Position: refs/heads/master@{#40551}
This CL removes code that is now unused since the port of regexp.js has been
completed. Removed functions / classes are:
* regexp.js (GetSubstitution moved to string.js)
* RegExpConstructResult stub
* RegExpFlags intrinsic
* RegExpSource intrinsic
* RegExpInitializeAndCompile runtime function
BUG=v8:5339
Review-Url: https://codereview.chromium.org/2448463002
Cr-Commit-Position: refs/heads/master@{#40547}
Now we
- always set .result to undefined before a visited loop and switch since we can't know whether they will set a value,
- only visit finally if it can break/continue; and only store/restore .result in that case
BUG=
Review-Url: https://codereview.chromium.org/2427253003
Cr-Commit-Position: refs/heads/master@{#40542}
CL https://codereview.chromium.org/2177273002 changed FastNewFunctionContextStub
to take a number of slots parameter and in-doing so removed the maximum slot
count for FastNewFunctionContextStub. This made it possible to create a
closure which is larger than kMaxRegularHeapObjectSize and so can't be
allocated by FastNewFunctionContextStub.
Reintroduce FastNewFunctionContextStub::kMaxSlots (but make the limit much
larger) to ensure we call the runtime for contexts which need to be
allocated in the LO space.
BUG=chromium:655573
Review-Url: https://codereview.chromium.org/2445703002
Cr-Commit-Position: refs/heads/master@{#40541}
This results in a speedup of around 2x. RegExpExec is also ported in
this CL.
BUG=v8:5339
Review-Url: https://codereview.chromium.org/2441993002
Cr-Commit-Position: refs/heads/master@{#40532}
The test ensures that in RegExp.prototype[@@split], exec is neither
accessed too early nor too often.
BUG=v8:5339,v8:5434
Review-Url: https://codereview.chromium.org/2440413002
Cr-Commit-Position: refs/heads/master@{#40526}
We need to check the KeyedLoadIC state to guard against potential
deoptimization loops due to out-of-bounds accesses, because the IC
system uses the MEGAMORPHIC state to also signal that there was an
out-of-bounds access already.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2443893002
Cr-Commit-Position: refs/heads/master@{#40525}
When lowering JSToLength, we cannot just smash arbitrary bounds on the
Select nodes, as that will confuse the representation selection later.
Instead properly rename the input using NumberMax and NumberMin.
R=jarin@chromium.org
BUG=chromium:657478
Review-Url: https://codereview.chromium.org/2440333002
Cr-Commit-Position: refs/heads/master@{#40519}
Since the public API for deserialization is now just DeserializeOrCompile,
we can trickle down the wire bytes to the deserialization logic, and
avoid the need for duplicating the wire bytes when serializing.
BUG=chromium:657316
Review-Url: https://chromiumcodereview.appspot.com/2433273002
Cr-Commit-Position: refs/heads/master@{#40516}
These map checks were implemented for TF code already. This CL makes
sure that parts implemented in C++ follow the same logic, which is:
An object is an unmodified regexp if:
1) it's a receiver,
2) its map is the initial regexp map,
3) its prototype is a receiver,
4) and its prototype's map is the initial prototype's initial map.
We can now be smarter in @@replace and @@split since checking maps
(unlike the previous check of RegExp.prototype.exec) is not observable,
so we can perform fast-path checks at a time of our choosing.
BUG=v8:5339,v8:5434,v8:5123
Review-Url: https://chromiumcodereview.appspot.com/2434983002
Cr-Commit-Position: refs/heads/master@{#40501}
Reason for revert:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/10853
Original issue's description:
> [regexp] Use consistent map checks for fast paths
>
> These map checks were implemented for TF code already. This CL makes
> sure that parts implemented in C++ follow the same logic, which is:
>
> An object is an unmodified regexp if:
> 1) it's a receiver,
> 2) its map is the initial regexp map,
> 3) its prototype is a receiver,
> 4) and its prototype's map is the initial prototype's initial map.
>
> We can now be smarter in @@replace and @@split since checking maps
> (unlike the previous check of RegExp.prototype.exec) is not observable,
> so we can perform fast-path checks at a time of our choosing.
>
> BUG=v8:5339,v8:5434,v8:5123
TBR=yangguo@chromium.org,jgruber@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5339,v8:5434,v8:5123
Review-Url: https://chromiumcodereview.appspot.com/2438283002
Cr-Commit-Position: refs/heads/master@{#40499}
These map checks were implemented for TF code already. This CL makes
sure that parts implemented in C++ follow the same logic, which is:
An object is an unmodified regexp if:
1) it's a receiver,
2) its map is the initial regexp map,
3) its prototype is a receiver,
4) and its prototype's map is the initial prototype's initial map.
We can now be smarter in @@replace and @@split since checking maps
(unlike the previous check of RegExp.prototype.exec) is not observable,
so we can perform fast-path checks at a time of our choosing.
BUG=v8:5339,v8:5434,v8:5123
Review-Url: https://chromiumcodereview.appspot.com/2434983002
Cr-Commit-Position: refs/heads/master@{#40495}
When the instance has imported memory, calling GrowMemory should update the memory object to have a consistent view of the memory. This fixes the failing emscripten test case, added a reduced test that simulates the same behavior.
R=titzer@chromium.org, dschuff@chromium.org
Review-Url: https://chromiumcodereview.appspot.com/2438673006
Cr-Commit-Position: refs/heads/master@{#40490}
This enables Ignition unconditionally for all code that is destined for
optimization with TurboFan. This ensures all optimization attempts will
go through the BytecodeGraphBuilder and that the AstGraphBuilder pipe is
dried out in practice.
R=mvstanton@chromium.org
Review-Url: https://chromiumcodereview.appspot.com/2427953002
Cr-Commit-Position: refs/heads/master@{#40462}
This CL refactors the handling of metadata associated with WebAssembly
modules to reduce the duplicate marshalling of data from the C++ world
to the JavaScript world. It does this by wrapping the C++ WasmModule*
object in a Foreign that is rooted from the on-heap WasmCompiledModule
(which is itself just a FixedArray). Upon serialization, the C++ object
is ignored and the original WASM wire bytes are serialized. Upon
deserialization, the C++ object is reconstituted by reparsing the bytes.
This is motivated by increasing complications in implementing the JS
API, in particular WebAssembly.Table, which must perform signature
canonicalization across instances.
Additionally, this CL implements the proper base + offset initialization
behavior for tables.
R=rossberg@chromium.org,bradnelson@chromium.org,mtrofin@chromium.org,yangguo@chromium.org
BUG=v8:5507, chromium:575167, chromium:657316
Review-Url: https://chromiumcodereview.appspot.com/2424623002
Cr-Commit-Position: refs/heads/master@{#40434}
Using uint32 to store the the number of control outputs allows WebAssembly switches to have more than 2^16 case.
BUG=v8:5531
TEST=mjsunit/regress/wasm/regression-5531
R=titzer@chromium.org
Review-Url: https://chromiumcodereview.appspot.com/2425983002
Cr-Commit-Position: refs/heads/master@{#40420}
When inlining JSCallConstruct in turbofan, receiver is initialized to model
the behaviour of constructor. When an implicit receiver is not required the
receiver value should be set to the hole value instead of undefined value.
When initializing the receiver via super calls, we check that the receiver
is the hole value.
BUG=chromium:653407
Review-Url: https://codereview.chromium.org/2424123002
Cr-Commit-Position: refs/heads/master@{#40396}
The inlined version of Array.prototype.push returned the value that was
pushed instead of the new "length" property value.
R=jarin@chromium.org
BUG=chromium:656037
Review-Url: https://codereview.chromium.org/2425903002
Cr-Commit-Position: refs/heads/master@{#40384}
1) assertInstanceOf(o, Foo, Bar) used to produce this error message:
Failure: expected <o> is not an instance of <Foo> but of < Bar>> found <undefined>
Fixed:
Failure: <o> is not an instance of <Foo> but of <Bar>
2) assertDoesNotThrow("throw 1") used to produce this error message:
Failure: expected <threw an exception: > found <1>
Fixed:
Failure: threw an exception: 1
3) assertDoesNotThrow("...", SomeError) was not doing what you'd
think it does, so removed the last parameter.
BUG=
Review-Url: https://codereview.chromium.org/2424743003
Cr-Commit-Position: refs/heads/master@{#40347}
There are a couple of operators that can indeed produce Float32
representation, which we might end up using in a TaggedSigned
context, so add the missing conversion (indirectly via Float64).
BUG=chromium:656275
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2421193002
Cr-Commit-Position: refs/heads/master@{#40334}
Reason for revert:
This is probably not working for falsey values. I cannot JavaScript :P
Original issue's description:
> mjsunit: Fix the error message produced by assertInstanceof.
>
> Used to be:
>
> Failure: expected <foo> is not an instance of <Bar> but of < Baz>> found <undefined>
>
> Should be:
>
> Failure: <foo> is not an instance of <Bar> but of <Baz>
>
> BUG=
>
> Committed: https://crrev.com/2a480eff395756f36eb0ae2fc0a573454b394268
> Cr-Commit-Position: refs/heads/master@{#40319}
TBR=verwaest@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/2421033003
Cr-Commit-Position: refs/heads/master@{#40331}
If the catch prediction machinery in the middle of some async op, we
shouldn't send invalid events to the debugger.
Instead of sending events with an undefined id, we don't send them at
all.
Review-Url: https://codereview.chromium.org/2417093003
Cr-Commit-Position: refs/heads/master@{#40327}
Used to be:
Failure: expected <foo> is not an instance of <Bar> but of < Baz>> found <undefined>
Should be:
Failure: <foo> is not an instance of <Bar> but of <Baz>
BUG=
Review-Url: https://codereview.chromium.org/2413153004
Cr-Commit-Position: refs/heads/master@{#40319}
A decoder error sets builder_ to null, which causes builder_->StackCheck
to segfault.
R=titzer@chromium.org
TEST=mjsunit/regress/wasm/loop-stack-check
Review-Url: https://codereview.chromium.org/2416873002
Cr-Commit-Position: refs/heads/master@{#40271}
This CL fixes the debugger interface to provide correct (high-level)
information for asm.js frames.
It moves the computation of the source position from the FrameInspector
to the individual StackFrame implementations, such that we can easily
specualize it for certain frame types, and can potentially reuse this
in other locations.
Also, we are finalizing the setup of the wasm module earlier, before
executing the start function. This is required for correct stack traces
during the execution of the start function.
R=titzer@chromium.org, yangguo@chromium.org
BUG=v8:4203
Review-Url: https://codereview.chromium.org/2413693003
Cr-Commit-Position: refs/heads/master@{#40268}
This moves the implementation of @@replace from regexp.js to builtins-regexp.cc
(the TurboFan fast path) and runtime-regexp.cc (slow path). The fast path
handles all cases in which the regexp itself is an unmodified JSRegExp
instance, the given 'replace' argument is not callable and does not contain any
'$' characters (i.e. we are doing a string replacement).
BUG=v8:5339
Review-Url: https://codereview.chromium.org/2398423002
Cr-Commit-Position: refs/heads/master@{#40253}
This fixes the code-path in RegExpExec in which both the passed exec
argument and regexp.exec are not callable and regexp is a JSRegExp.
In this case, we fall back to the default RegExp.prototype.exec
implementation. The arguments for Execution::call were incorrect.
BUG=v8:5339
Review-Url: https://codereview.chromium.org/2415073002
Cr-Commit-Position: refs/heads/master@{#40249}
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}
For the asm.js to WASM pipeline, the current stack traces only show
low-level WASM information.
This CL maps this back to asm.js source positions.
It does so by attaching the asm.js source Script to the compiled WASM
module, and emitting a delta-encoded table which maps from WASM byte
offsets to positions within that Script. As asm.js code does not throw
exceptions, we only store a mapping for call instructions.
The new AsmJsWasmStackFrame implementation inherits from
WasmStackFrame, but contains the logic to provide the source script and
the position inside of it.
What is still missing is the JSFunction object returned by
CallSite.getFunction(). We currently return null.
R=jgruber@chromium.org, titzer@chromium.org
BUG=v8:4203
Review-Url: https://codereview.chromium.org/2404253002
Cr-Commit-Position: refs/heads/master@{#40205}
We accidently dropped the effect on the floor that we have for the
polymorphic map check in case of array elements access.
BUG=chromium:655004
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2411273002
Cr-Commit-Position: refs/heads/master@{#40201}
For ConsString, the left hand side must be either sequential or external
if the right hand side is empty.
R=jarin@chromium.org
BUG=chromium:654723
NOTRY=true
Review-Url: https://codereview.chromium.org/2410893003
Cr-Commit-Position: refs/heads/master@{#40192}
This test is timing out in gc-stress mode since RegExp.prototype.test
was moved to C++. RE.proto.test will be improved shortly, and this test
should be reenabled then.
BUG=v8:5339
NOTRY=true
Review-Url: https://codereview.chromium.org/2407133002
Cr-Commit-Position: refs/heads/master@{#40150}
Extend a test of namespace imports such that it accesses the object inside a
with statement (inside a sloppy function).
Drive-by-fix: remove duplicate initialization of embedder data (probably due to
bad merge).
R=adamk@chromium.org
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2405603003
Cr-Commit-Position: refs/heads/master@{#40129}
Also add a test for when the first argument is null or undefined, as there are no tests that cover this currently.
BUG=v8:5364
Review-Url: https://codereview.chromium.org/2399423003
Cr-Commit-Position: refs/heads/master@{#40127}
The spurious failures were caused by the compiled module
template and its corresponding owning object getting out of
sync due to memory allocations (which may trigger GC)
between the points each were fetched.
Specifically, the {original} was first obtained; then a GC
may happen when cloning the {code_table}. At this point,
the {original}'s owner may have been collected, getting us
down the path of not cloning. When time comes to patch up
globals, we incorrectly try to patch them assuming the
global start is at 0 (nullptr), which in fact it isn't.
This change roots early, in a GC-free area, both objects.
Additionally, it avoids publishing to the instances chain
the new instance until the very end. This way:
- the objects used to create the new instance offer a
consistent view
- the instances chain does not see the object we try to
form. If something fails, we can safely retry.
- since the owner is rooted, the state of the front of the
instances chain stays unchanged - with the same compiled
module we started from. So the early belief that we needed
to clone is not invalidated by any interspersed GC.
This situation suffers from a sub-optimality discussed in
the design document, in that, in a memory constrained
system, the following snippet may surprisingly fail:
var m = new WebAssembly.Module(...);
var i1 = new WebAssembly.Instance(m);
i1 = null;
var i2 = new WebAssembly.Instance(m); //may fail.
This will be addressed subsequently.
BUG=v8:5451
Review-Url: https://codereview.chromium.org/2395063002
Cr-Commit-Position: refs/heads/master@{#40126}
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}
There were once plans to generate cross-context code with TurboFan,
however that doesn't fit into the model anymore, and so all of this
is essentially dead untested code (and thus most likely already broken
in subtle ways). With this mode still in place it would also be a lot
harder to make inlining based on SharedFunctionInfo work.
BUG=v8:2206,v8:5499
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2406803002
Cr-Commit-Position: refs/heads/master@{#40109}
This implements namespace imports (import * as foo from "bar"), except for the
@@iterator property on namespace objects (to be done later).
R=adamk@chromium.org
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2388153003
Cr-Commit-Position: refs/heads/master@{#40096}
- Added gating code in the module-decoder to allow SIMD code only when
it can be decoded correctly
- SIMD128 values should not be exported to JS
- Try/Catch should not be available in asmjs modules
- Trivial fixes for S128 values
BUG=chromium:648079
R=ahaas@chromium.org, titzer@chromium.org, bradnelson@chromium.org
Review-Url: https://codereview.chromium.org/2400863003
Cr-Commit-Position: refs/heads/master@{#40067}
This patch sets `this` to be undefined when calling resolve and reject
functions attached to the deferred.
BUG=v8:5476
Review-Url: https://codereview.chromium.org/2399053003
Cr-Commit-Position: refs/heads/master@{#40056}
Imports and exports in 0xC can be much more than functions, including
tables, memories, and globals. This CL refactors the underlying
organization of imports and exports to support these new import types.
BUG=
Committed: https://crrev.com/599f8a83420346d9cba5ff97bd2a7520468207b6
Review-Url: https://codereview.chromium.org/2390113003
Cr-Original-Commit-Position: refs/heads/master@{#40033}
Cr-Commit-Position: refs/heads/master@{#40050}
Imports and exports in 0xC can be much more than functions, including
tables, memories, and globals. This CL refactors the underlying
organization of imports and exports to support these new import types.
BUG=
Review-Url: https://codereview.chromium.org/2390113003
Cr-Commit-Position: refs/heads/master@{#40033}
Fixes:
- Remove OsrGuards on frame specialization (for asm.js).
- Handle the rename in the walk for native context.
- Fix LoadContext effect wiring for Osr context chains.
Review-Url: https://codereview.chromium.org/2388303006
Cr-Commit-Position: refs/heads/master@{#40021}
Allow fround to take values without dots for globals (the spec allows this
subtly).
Drop over-restrictive assert preventing floating point globals from working.
BUG=v8:4203
R=jpp@chromium.org,aseemgarg@chromium.org
Review-Url: https://codereview.chromium.org/2397823003
Cr-Commit-Position: refs/heads/master@{#40013}
This makes sure we run the module tests against all variants using
Ignition as the first compilation tier. It will henceforth extend the
test coverage to the BytecodeGraphBuilder as well.
R=neis@chromium.org
Review-Url: https://codereview.chromium.org/2397733002
Cr-Commit-Position: refs/heads/master@{#39992}
Reason for revert:
Tanks the world.
Original issue's description:
> [turbofan] Osr value typing + dynamic type checks on entry.
>
> This introduces a new OsrGuard node that is inserted during graph building
> to guard the inferred type of the OSR value.
>
> The type of the OSR value is inferred by running the typer before OSR
> deconstruction, and then taking the type from the phi that takes the
> OSR value. After the deconstruction, we throw the types away.
>
> At the moment we only support the SignedSmall OSR type and we always
> pick the tagged representation. Later, we might want to support more
> types (such as Number) and pick better representations (int32/float64).
>
> This CL also removes the OSR deconstruction tests because they build
> unrealistic graph (no effect chain, no loop termination). I considered
> adding the effect chains to the tests, but this would make the tests
> even more brittle.
>
> Committed: https://crrev.com/1f5dc90a900d222da44bee3eff171a2ba1e3c076
> Cr-Commit-Position: refs/heads/master@{#39971}
TBR=bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2395783002
Cr-Commit-Position: refs/heads/master@{#39985}
The implementation of MemorySize with RelocatableInt32Constants is
problematic if MemorySize is placed close to a GrowMemory instruction in
the code. The use of a runtime function guarantees that the order in
which MemorySize and GrowMemory is executed is correct.
R=titzer@chromium.org
BUG=chromium:651961
TEST=mjsunit/regress/wasm/regression-651961
Committed: https://crrev.com/2c12a9a42d454a36fcd2931fa458d72832eeb689
Review-Url: https://codereview.chromium.org/2386183004
Cr-Original-Commit-Position: refs/heads/master@{#39972}
Cr-Commit-Position: refs/heads/master@{#39980}
Reason for revert:
Patch problem
Original issue's description:
> [wasm] Call a runtime function for a MemorySize instruction.
>
> The implementation of MemorySize with RelocatableInt32Constants is
> problematic if MemorySize is placed close to a GrowMemory instruction in
> the code. The use of a runtime function guarantees that the order in
> which MemorySize and GrowMemory is executed is correct.
>
> R=titzer@chromium.org
> BUG=chromium:651961
> TEST=mjsunit/regress/wasm/regression-651961
>
> Committed: https://crrev.com/2c12a9a42d454a36fcd2931fa458d72832eeb689
> Cr-Commit-Position: refs/heads/master@{#39972}
TBR=titzer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:651961
Review-Url: https://codereview.chromium.org/2391223002
Cr-Commit-Position: refs/heads/master@{#39973}
The implementation of MemorySize with RelocatableInt32Constants is
problematic if MemorySize is placed close to a GrowMemory instruction in
the code. The use of a runtime function guarantees that the order in
which MemorySize and GrowMemory is executed is correct.
R=titzer@chromium.org
BUG=chromium:651961
TEST=mjsunit/regress/wasm/regression-651961
Review-Url: https://codereview.chromium.org/2386183004
Cr-Commit-Position: refs/heads/master@{#39972}
This introduces a new OsrGuard node that is inserted during graph building
to guard the inferred type of the OSR value.
The type of the OSR value is inferred by running the typer before OSR
deconstruction, and then taking the type from the phi that takes the
OSR value. After the deconstruction, we throw the types away.
At the moment we only support the SignedSmall OSR type and we always
pick the tagged representation. Later, we might want to support more
types (such as Number) and pick better representations (int32/float64).
This CL also removes the OSR deconstruction tests because they build
unrealistic graph (no effect chain, no loop termination). I considered
adding the effect chains to the tests, but this would make the tests
even more brittle.
Review-Url: https://codereview.chromium.org/2384113002
Cr-Commit-Position: refs/heads/master@{#39971}
This fixes a gc stress bug. We cannot rely on an ordering of
clearing of the weak cells, so we explicitly reset the weak
link to the owning instance, when finalizing a compiled
module. In turn, this serves as a reliable signal when GCs
happen while instantiating, allowing us to correctly link the
new instance.
BUG=chromium:652425
Review-Url: https://codereview.chromium.org/2393443003
Cr-Commit-Position: refs/heads/master@{#39964}
Previously, b6e9f625c1 fixed self-assignment
in parameters to throw. But it failed to deal with the case of
destructuring with defaults. This patch extends that previous approach
to always treat the end of a parameter as its initializer position,
whether it has an initializer or not.
This is the minimal change to make it easy to merge; a follow-up
will rename the field of Parameter from "initializer_end_position"
to "end_position".
BUG=v8:5454
Review-Url: https://codereview.chromium.org/2390943002
Cr-Commit-Position: refs/heads/master@{#39962}
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}
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}
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}
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}
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}
Note that the offset can still be out of bounds, even after grow memory. The calculation of the remaining size can overflow.
R=gdeepti@chromium.org
BUG=chromium:644670
Review-Url: https://codereview.chromium.org/2376153003
Cr-Commit-Position: refs/heads/master@{#39886}
Making new nodes inside of exception-handled blocks fiddles around with the
current environment to merge the exception paths. In particular, the current
environment pointer is mutated. This patch ensures that when we merge the fast
and slow paths of the LdaContextLookup, we actually merge the correct
environment and do not accidentally merge the exceptional environment.
BUG=chromium:651394
Review-Url: https://codereview.chromium.org/2379043002
Cr-Commit-Position: refs/heads/master@{#39878}
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}
