Instead of calling {TryAllocateBackingStore} with
{enable_guard_regions==false}, we just directly call
{array_buffer_allocator->Allocate}.
Drive-by optimization: Don't allocate if the size is 0.
R=titzer@chromium.org
Change-Id: Iabf7af7e0f1bc970c03efcd9ee4c23e5307a7095
Reviewed-on: https://chromium-review.googlesource.com/548398
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46218}
This prepares switching the gcov coverage bot to GN.
We skip instrumenting test executables explicitly in gn configs.
In gyp, we did the same through an extra compiler wrapper script.
NOTRY=true
Bug: chromium:645890
Change-Id: I663fb479347063ae9228598d356bb654ca2a496c
Reviewed-on: https://chromium-review.googlesource.com/548275
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46217}
This removes specialized support for materializing arguments objects.
For TurboFan we use the generic escape analysis mechanism when such
objects are materialized already, only Crankshaft used this deprecated
mechanism.
R=jarin@chromium.org
BUG=v8:6408
Change-Id: Ibed52a028752e667b05a60fa7cf0275a6a372897
Reviewed-on: https://chromium-review.googlesource.com/548595
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46215}
The only difference between GetNextUncompiledFunctionId +
CompileAndSchedule and FetchAndExecuteCompilationUnit is that
FetchAndExecuteCompilationUnit potentially calls a callback if
it detects that no finishing task is executing. With this CL
I replace the two functions again with
FetchAndExecuteCompilationUnit. I add a flag so that no callback
is called when the flag is not set. If no callback is called,
FetchAndExecuteCompilationUnit behaves exactly the same
as the other two functions together.
R=clemensh@chromium.org
Change-Id: I17318381eec2d17b13d0902984f2620b909c7ea0
Reviewed-on: https://chromium-review.googlesource.com/544954
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46210}
If the data to be stored in a BitVector is small enough (less than the
pointer size), it can be stored directly on the BitVector instead of the
pointer. This patch makes the data field of the BitVector a union
between a pointer and uintptr_t, and uses the latter is the data length
is 0.
Change-Id: I24c1920f2c16373c883cf69b123bf59812fef28e
Reviewed-on: https://chromium-review.googlesource.com/541307
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46209}
This is mainly to enable optimization of case-insensitive maps, where
we see the pattern
if (m.has(key.toLowerCase())) { return m.get(key.toLowerCase()) } ...
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I8c78a185401c51e8a53ae2932a158eaafa169495
Reviewed-on: https://chromium-review.googlesource.com/547057
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46206}
There were only two uses. Replace them by [[noreturn]] directly.
R=jarin@chromium.org
BUG=v8:6474
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I965f74f5b3493cfef9efd698f24bf00216442fd8
Reviewed-on: https://chromium-review.googlesource.com/544845
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46205}
Previously any object with maps INTERNALIZED_STRING_TYPE or
ONE_BYTE_INTERNALIZED_STRING_TYPE would be typed as kInternalizedString.
This meant that non-empty constants weren't typed as such. This causes the
following issues:
- StringConcat couldn't be typed lowered to inline cons string allocation
if there were string constants after the first two operands, since these
constants would be typed as possibly empty (even if known not to be).
- When inlining, a heap constant could end up becoming the input to a
ToPrimitiveToString operand. If the ToPrimitiveToString is speculatively
lowered to a CheckNonEmpty, then the verifier would fail since the
typer can't deal well with intersecting a bitset type (NonEmpty) with
a HeapConstantType - the end result type would be (None | HeapConstant..)
but the HeapConstantType would retain it's LUB of kInternalizedSeqString,
(which includes the EmptyString type) and so the verifier would fail
since the output of CheckNonEmpty would still include the EmptyString.
To address this, when typing an actual object, check for the empty
string and return EmptyString if it is, otherwise type as normal but
remove the EmptyString bit since we know it's non-empty.
BUG=v8:6243
Change-Id: I2b34ca24e9b488199dce0d2c092d2701c2b22791
Reviewed-on: https://chromium-review.googlesource.com/544988
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46204}
This is a regression test that will ensure that follow-up CLs that will
touch native function definitions will not brake anything.
Bug: v8:6459
Change-Id: Iceafd38462f2d9de14e119b6aa48be2b9bff1d33
Reviewed-on: https://chromium-review.googlesource.com/545935
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46200}
Reason for revert:
Blocks roll:
https://codereview.chromium.org/2954833002/
E.g.:
https://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_compile_dbg_ng/builds/449680https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_compile_dbg_ng/builds/324953
Please include those chromium trybots on reland. Maybe missing symbol export?
Original issue's description:
> Make some functions that are hit during renderer startup available for inlining
>
> This is towards closing the perf gap between the MSVC build (which uses link-
> time optimization) and Clang (where LTO isn't ready on Windows yet). We did
> a study (see bug) to see which non-inlined functions are hit a lot during render
> start-up, and which would be inlined during LTO. This should benefit performance
> in all builds which currently don't use LTO (Android, Linux, Mac) as well as
> the Win/Clang build.
>
> The binary size of chrome_child.dll increases by 2KB with this.
>
> BUG=chromium:728324
>
> Review-Url: https://codereview.chromium.org/2950993002
> Cr-Commit-Position: refs/heads/master@{#46191}
> Committed: d00d52be1fTBR=jochen@chromium.org,mstarzinger@chromium.org,rmcilroy@chromium.org,vogelheim@chromium.org,marja@chromium.org,mlippautz@chromium.org,thakis@chromium.org,hans@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:728324
NOTRY=true
NOPRESUBMIT=true
Review-Url: https://codereview.chromium.org/2955793002
Cr-Commit-Position: refs/heads/master@{#46195}
This is towards closing the perf gap between the MSVC build (which uses link-
time optimization) and Clang (where LTO isn't ready on Windows yet). We did
a study (see bug) to see which non-inlined functions are hit a lot during render
start-up, and which would be inlined during LTO. This should benefit performance
in all builds which currently don't use LTO (Android, Linux, Mac) as well as
the Win/Clang build.
The binary size of chrome_child.dll increases by 2KB with this.
BUG=chromium:728324
Review-Url: https://codereview.chromium.org/2950993002
Cr-Commit-Position: refs/heads/master@{#46191}
This is a fix to https://codereview.chromium.org/2929853003 that got
reverted. The DCHECK checked to see that it was not in a background
thread. While this is a property we want for v8, it is also used
by blink, and blink violates this property.
Therefore, this CL removes the DCHECK for now.
BUG=v8:6361
Review-Url: https://codereview.chromium.org/2961443002
Cr-Commit-Position: refs/heads/master@{#46190}
Port 217012973c
Original Commit Message:
Add a new JSConstructWithArrayLike operator that is backed by the
ConstructWithArrayLike builtin (similar to what was done before
for the JSCallWithArrayLike operator), and use that operator to
optimize Reflect.construct inlining in TurboFan. This is handled
uniformly with JSConstructWithSpread in the JSCallReducer.
Also add missing test coverage for Reflect.construct in optimized
code, especially for some interesting corner cases.
R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:4587,v8:5269
LOG=N
Change-Id: Idaf247317036ddec74b9aa3addd2e7d75b65bfaf
Reviewed-on: https://chromium-review.googlesource.com/546716
Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com>
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#46189}
Port 767ce78871
Original Commit Message:
Add a new JSCallWithArrayLike operator that is backed by the
CallWithArrayLike builtin, and use that operator for both
Function.prototype.apply and Reflect.apply inlining. Also unify
the handling of JSCallWithArrayLike and JSCallWithSpread in
the JSCallReducer to reduce the copy&paste overhead.
Function.prototype.apply in optimized code, especially for some
corner cases, which was missing so far.
R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:4587,v8:5269
LOG=N
Change-Id: I930845df7e87b8962588cc79f6069477865fa086
Reviewed-on: https://chromium-review.googlesource.com/546735
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#46188}
Port a971a64d1c
Original Commit Message:
We can remove a lot of native code and rely on CallOrConstructVarargs
to do the stack manipulation for us.
This will also take advantage of the fast-path for double arrays in
CallOrConstructDoubleVarargs.
We can also remove Runtime_SpreadIterableFixed because it isn't used
anymore. We just call directly into spread_iterable from CSA.
R=petermarshall@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: Idad830c9aace4151db866c9f863158cd7525e881
Reviewed-on: https://chromium-review.googlesource.com/546575
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#46187}
Each frame within an optimized frame needs to be re-verified as being
subject to debugging. The specific crash from the linked bug was caused
by the fact that non-user JS frames don't necessarily have an associated
script. We'd ignore that and attempt to call
Script::GetPositionInfo() on the Undefined constant.
BUG=chromium:732408
Change-Id: Ib2982890529623d150092fa57e26fcb237fef59f
Reviewed-on: https://chromium-review.googlesource.com/545895
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46186}
When executing a script that does import("foo"), "foo" should be
relative to the script's directory, not relative to the current working
directory of the d8 process.
R=gsathya@chromium.org
Bug: v8:5785
Change-Id: Id6ceccb242905bd6b54b07038ece60b93d92e4a0
Reviewed-on: https://chromium-review.googlesource.com/546375
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46185}
In bits.h, instead of relying on C++ overloading for 32/64 bits integers
(which can be ambiguous when the input isn't the exact type typedef-ed
by uint64_t or uint32_t), use templates and std::enable_if to switch
between integers of different sizes.
This means that we can get rid of an awkward sizeof check in
bit-vector.cc, which was necessary to compile on Mac.
Change-Id: Id0eaf0f855cdbd2dc4d7bc1c481037fcd9b73953
Reviewed-on: https://chromium-review.googlesource.com/543480
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46184}
Move bytecode array writing logic into the array builder, allowing us to
remove the bytecode array writer and bytecode node, and convert runtime
operand writing to compile-time bytecode operand writing using the
information statically known at compile time.
Bug: v8:6474
Change-Id: I210cd9897fd41293745614e4a253c7c251dfffc9
Reviewed-on: https://chromium-review.googlesource.com/533055
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46183}
This prepares ground for switching mark-compactor to use
Worklist data-structure instead of the existing marking deque.
BUG=chromium:694255
Change-Id: I0ac4c563018a9619962fb4bf388b5f3cceffb86d
Reviewed-on: https://chromium-review.googlesource.com/544933
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46178}
The race happens when the layout descriptor is evacuated at the same
time as an object that has this layout descriptor is evacuated.
Change-Id: I0a5fc545cf359fdfe738d8b6359713f5ea170986
Reviewed-on: https://chromium-review.googlesource.com/544953
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46175}
This reverts commit 217d654c9b.
Reason for revert: Changes layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/16520
Original change's description:
> [parser] moved load property position after dot
>
> Currently LdaNamedProperty bytecode for expressions like a.b has position before dot. This CL moves this location after dot.
> It's important for later removing of Nop bytecodes in expressions like a.b() where a is local variable, property call and property load should have the same position.
>
> R=jgruber@chromium.org
>
> Bug: v8:6425
> Change-Id: I528c5007de52215beba80851ab04693ecec038e2
> Reviewed-on: https://chromium-review.googlesource.com/543047
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46163}
TBR=marja@chromium.org,kozyatinskiy@chromium.org,jgruber@chromium.org
Change-Id: I94543526f39f0a20452fbce1a7bc6744cac66621
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6425
Reviewed-on: https://chromium-review.googlesource.com/544993
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46171}
For correct error positions, the FunctionBody struct stored a {base}
pointer to the beginning of the wasm module bytes, in addition to the
{start} and {end} pointer of the function body within the module bytes.
For streaming compilation, we do not have all module bytes in a single
chunk of memory. Therefore this CL changes the FunctionBody such that it
does not store the base pointer but the offset of the function body
within the module. I did the same change already some time ago for the
{Decoder}.
R=clemensh@chromium.org, mtrofin@chromium.org
Change-Id: I5138fbe270d0f5166a7dcc5cb8f3fe78a298bff6
Reviewed-on: https://chromium-review.googlesource.com/544863
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46170}
