The feedback collection was decoupled from the actual comparison in the
compare bytecode handlers. This involves checks on the type of operands both
when collecting the feedback and when performing the operation. To avoid this
the type feedback is collected inline with the actual comparison.
This cl inlines the type feedback collection for the StrictEqual bytecode
handler. The other compare operations will be handled in subsequent cls.
Bug:
Change-Id: I429ed3c58b344c1c492e743c190bf16ab991ce6e
Reviewed-on: https://chromium-review.googlesource.com/483399
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44919}
Currently, the external API (e.g. v8::Object::Get()) will enter the
context passed to it automatically. This is incorrect and causes some
trouble for Blink, so we want to change that.
It then becomes a potential problem to call the external API without
first entering a context, which the inspector code does in some
places. This patch aims to correct this.
BUG=v8:6307
Review-Url: https://codereview.chromium.org/2841053002
Cr-Commit-Position: refs/heads/master@{#44917}
This is a highly requested feature!
Bug: v8:6276
Change-Id: I17b606ae0ff8fa9dfdd0fa74fd1f7ad0dd3fc4f8
Reviewed-on: https://chromium-review.googlesource.com/488044
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44916}
When accessing JSArray::length property from GenericPropertyLoad
(i.e. via a megamorphic KEYED_LOAD_IC), we'd always go to the runtime
at this point, because the CallGetterIfAccessor method didn't support
AccessorInfos at all. Now there's initial support for JSArray::length,
which reduces the number of %KeyedGetProperty calls we see in the
Speedometer/EmberJS test by 5000.
Also-By: ishell@chromium.org
BUG=v8:5269
R=ishell@chromium.org
Change-Id: I44ce7966f9b7257808110a24d95a8167ab035df9
Reviewed-on: https://chromium-review.googlesource.com/488224
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44915}
The AccessorAssembler::GenericPropertyLoad case went to
%KeyedGetProperty when the actual handler that we found
in the stub cache would miss. In this case we would always
fall into the same trap all the time, since no one updates
the stub cache.
BUG=v8:5269
R=ishell@chromium.org
Change-Id: I90fd83337c320f194dc31a69716627d047a6b070
Also-By: ishell@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/488147
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44914}
Performance regressed for this with the I+TF switch. This speeds up
the simple case by using optimizations in the elements accessor.
Bug: chromium:700835
Change-Id: Iaba30951b93daefa0fb32acd6656ac705cdc73ed
Reviewed-on: https://chromium-review.googlesource.com/483341
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44913}
kNumberOfSpaces includes map and large object spaces,
kNumberOfPreallocatedSpaces does not. Therefore we need
to output both separately.
R=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2843353002
Cr-Commit-Position: refs/heads/master@{#44912}
This reverts commit d7cdea6fa2.
Reason for revert: Flakiness on bots
Original change's description:
> [wasm] Add guard pages before Wasm Memory
>
> Although Wasm memory indices are all unsigned, they sometimes get assembled
> as 32-bit signed immediates. Values in the top half of the Wasm memory space
> will then get sign extended, causing Wasm to access in front of its memory
> buffer.
>
> Usually this region is not mapped anyway, so faults still happen as they are
> supposed to. This change protects this region with guard pages so we are
> guaranteed to always fault when this happens.
>
> Bug: v8:5277
> Change-Id: Id791fbe2a5ac1b1d75460e65c72b5b9db2a47ee7
> Reviewed-on: https://chromium-review.googlesource.com/484747
> Commit-Queue: Eric Holk <eholk@chromium.org>
> Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#44905}
TBR=bradnelson@chromium.org,gdeepti@chromium.org,mtrofin@chromium.org,eholk@chromium.org,mseaborn@chromium.org,adamk@chromium.org,v8-reviews@googlegroups.com,wasm-v8@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: Ia1d3e5dbf4f518815a9fd4197047077bc8e42816
Reviewed-on: https://chromium-review.googlesource.com/487828
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44907}
Clearing out the constructor field is invalid in the case where the
function's map has transitioned since the last SetPrototype call.
Bug: chromium:714972
Change-Id: Ie918702a128219c4995b805f7c9a53b41cc4e4b6
Reviewed-on: https://chromium-review.googlesource.com/486130
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44906}
Although Wasm memory indices are all unsigned, they sometimes get assembled
as 32-bit signed immediates. Values in the top half of the Wasm memory space
will then get sign extended, causing Wasm to access in front of its memory
buffer.
Usually this region is not mapped anyway, so faults still happen as they are
supposed to. This change protects this region with guard pages so we are
guaranteed to always fault when this happens.
Bug: v8:5277
Change-Id: Id791fbe2a5ac1b1d75460e65c72b5b9db2a47ee7
Reviewed-on: https://chromium-review.googlesource.com/484747
Commit-Queue: Eric Holk <eholk@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44905}
This allows us to avoid a separate receiver typecheck in a few places
without regressing the error messages generated.
As more Array methods move to C++, this will get more usage.
Bug: v8:3577
Change-Id: Ibdd17c781548520172ce62442bc3a800e5c09e99
Reviewed-on: https://chromium-review.googlesource.com/486103
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44904}
The interpreter used a ZoneVector<WasmVal> to model the value stack.
Thus, at each single pop to the stack, a bounds check was performed,
and the storage was potentially extended.
This CL changes this to pre-allocate enough space for the stack of a
function when a new frame is entered. This avoids any checks for pushs
and pops.
Instead of storing a ZoneVector<WasmVal>, we store WasmVal* directly.
The maximum value stack size is precomputed together with the control
transfer side table.
This CL speeds up interpreted execution by 15% on average (measured
locally on a Z840).
R=ahaas@chromium.org
BUG=v8:5822
Change-Id: If949f7ee5233d874cd6a04b7dde2d7b4a95e45ea
Reviewed-on: https://chromium-review.googlesource.com/488061
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44902}
This still doesn't cover all the paths yet, since some paths are
impossible to trigger at this point due to the way the CanInlineCall
predicate works on the AllocationSite, which says multiple things:
- In case of Array(len), the len was always a Smi so far.
- In case of Array(...args), storing the args didn't change the
elements kind.
- In case of Array(len), the len was always less than the initial
maximum fast element array size.
These conditions are tailored towards Crankshaft and don't really
make a lot of sense in the TurboFan world. We'd need more fine
grained protections, which we will achieve by refactoring the Array
constructor.
BUG=chromium:715404,v8:6262
TBR=machenbach@chromium.org
Review-Url: https://codereview.chromium.org/2843033002
Cr-Commit-Position: refs/heads/master@{#44901}
For holey Smi and double source arrays, we would go to the general
case, which is much slower than before. We already check that there
are no prototype chain changes in IterableToListCanBeElided, and
there is no JS-code run between that check and the copying of the
elements, so we can safely check for the hole and convert it to
undefined, which is then converted to 0/NaN appropriately for the
given TypedArray.
Bug: chromium:713570,chromium:711275
Change-Id: I5b21c915907d71eebb73b7b1eea8eb58b4a5436d
Reviewed-on: https://chromium-review.googlesource.com/485520
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44899}
At the moment the AsyncCompileJob object is deallocated after one of its
task functions return false. This mechanism is, however, not documented,
potentially error-prone, and I think there are already some cases where
I think that we got it wrong.
This CL moves the deallocation of the AsyncCompileJob object to the
place where the promise which belongs to the AsyncCompileJob is either
resolved or rejected. This is a more appropriate place to deallocate the
object, because conceptionally, at the end of every an AsyncCompileJob
its promise should either be resolved or rejected.
R=clemensh@chromium.org, mtrofin@chromium.org
Change-Id: I87618c5619a3ac923645d1c3f6acaee9b0b14a83
Reviewed-on: https://chromium-review.googlesource.com/486884
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44896}
Reason for revert:
Field representation is not preserved
Original issue's description:
> [turbofan] Set proper representation for initial arguments length.
>
> The JSArgumentsObject::length representation is initially Smi, so we can
> record that on the initial map and use it to optimize the accesses in
> TurboFan based on that. Similar for JSSloppyArgumentsObject::caller.
>
> BUG=v8:6262
> R=yangguo@chromium.org
>
> Review-Url: https://codereview.chromium.org/2810333004
> Cr-Commit-Position: refs/heads/master@{#44644}
> Committed: 5eec7df9b3TBR=yangguo@chromium.org,bmeurer@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:6262
Review-Url: https://codereview.chromium.org/2825323002
Cr-Commit-Position: refs/heads/master@{#44893}
This makes sure that the observable property order of the module export
maintains insertion order. Now that properties are configurable, we no
longer need to reverse the export processing.
R=clemensh@chromium.org
TEST=mjsunit/asm/asm-validation
BUG=chromium:715420
Change-Id: Ib2024254c07bdad7fee1cf2fa0bd3e847721f5b5
Reviewed-on: https://chromium-review.googlesource.com/488022
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44891}
This fixes the bounds checking of "unsigned" numeric literals (those
that do not contains dots) by the parser. In particular this fixes a
bogus truncation to 32-bit in the scanner. It also makes the scanner
more robust by limiting the range of those numeric literals, hence
completely avoiding rounding loss or truncation errors.
R=clemensh@chromium.org
TEST=unittests/AsmJsScannerTest.UnsignedNumbers
BUG=v8:6298
Change-Id: Id31ab3c652e99fa8d3d6663315768e1bfaf3b773
Reviewed-on: https://chromium-review.googlesource.com/486881
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44890}
Instead of calculating the OSR entry point both in the bytecode analysis
and in the bytecode graph builder, calculate it once in the analysis and
use that calculation in the graph builder.
Old TODO from https://codereview.chromium.org/2558093005.
Change-Id: I071bc622beb55dc5eddaee25ef28e21fc4b477f0
Reviewed-on: https://chromium-review.googlesource.com/485899
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44888}
This makes e.g., load(file) work within Realm.eval(realm, "load(file)") to load files into that realm.
Bug:
Change-Id: I85738f0dfab621f2a8c9e2703f4ce4b39dd882bf
Reviewed-on: https://chromium-review.googlesource.com/484379
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44887}
Only create a singleton array for Array(len) if Type(len) cannot be
Number, otherwise we might need to throw an exception instead.
BUG=chromium:715404
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2838123004
Cr-Commit-Position: refs/heads/master@{#44886}
The only users of the LoadStoreOpcodeOf function were a number of
macros in wasm-macro-gen.h, and three test functions using it directly.
This CL refactors those functions to also use the macros.
In one case, this requires storing the value in a local variable first.
R=ahaas@chromium.org
Change-Id: Ia2fbf67a3831fafc9345e155eb240cf1bf6feb5d
Reviewed-on: https://chromium-review.googlesource.com/486842
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44885}
Update the json file in js-perf-test with compare bytecode handler tests.
This cl (https://chromium-review.googlesource.com/c/485522/) adds new
tests but not all of them are updated in the json file.
Bug:v8:4280
Change-Id: Ifd1f479b770a4277fbba1de51ca2f7cbc26003cb
Reviewed-on: https://chromium-review.googlesource.com/487961
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44879}
Previously API function calls would only be optimized in TurboFan when
the receiver was a (compile-time) known constant, which was probably
only true for certain cases where functions where called on the global
proxy (the window object).
BUG=v8:5267,v8:6304
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2839953002
Cr-Commit-Position: refs/heads/master@{#44877}
Although we currently only support up to 1GB memory, we want to raise
this issue in the future. This test illustrates several issues we need
to be sure to fix first.
Bug: v8:6306
Change-Id: I362b7a9e51e8eb33a50e3b172a6f01d41995c3cb
Reviewed-on: https://chromium-review.googlesource.com/487047
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44876}
Port 46d0e4818a
Original Commit Message:
The CallApiCallbackStub can avoid loading undefined in case the
call_data is already undefined, which doubles the number of versions of
the stub and adds unnecessary complexity (at the benefit of saving one
stupid load). The idea is to turn the CallApiCallbackStub into a single
builtin instead, which does the right thing, so this is the first step
towards that goal.
R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:6304
LOG=N
Review-Url: https://codereview.chromium.org/2837283004
Cr-Commit-Position: refs/heads/master@{#44872}
