We were using 'strtoll' which returns a signed integer, we should have used
'strtoull' instead.
Change-Id: Ie2e48ecc1fa58cff4b61fcea30087608769a80bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893333
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#64765}
This is the last remaining missing instruction from the MVP. This CL
adds support for ia32, x64, arm, and arm64.
For CPUs which do not support the POPCNT instruction, there exists a
fallback implementation in C.
R=jkummerow@chromium.org
Bug: v8:9919
Change-Id: Ie7a79a46e91726e15379b9a21b59775bbf5de556
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895569
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64764}
Instead of inferring allow_codegen from the state of MaybeLocal<String>, return it separately. This allows to distinguish "could not stringify this object" from "block execution of this object", regardless of whether the object is a string or not. Currently, the hook can trigger an EvalError only if the original source was a string.
Modify the logic so that one of the three mechanisms (unconditional, non-modifying, modifying) decides alone. Before, if the non-modifying callback rejected a value, the value would be forwarded to the modifying callback, but the unconditional would not forward to the non-modifying callback. This introduces a more uniform behaviour where the three mechanisms act in decreasing priority.
Change-Id: Iaaa9873227052653d714df65f31c4de914f48b7d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1776082
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Stefano Sanfilippo <ssanfilippo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64763}
The heap profiler and debugger use allocation trackers to observe allocation
events and need to disable inlined allocations temporarily. But if
--no-inline-new is passed, they do not need to.
However, when removing allocation trackers they would accidently enable it
again.
Bug: v8:9906
Change-Id: I6f8322886a3ada66d3f1cc26f0e321a9863dcf08
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895572
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#64762}
The {pinned} argument is always an empty register list now. Hence this
CL removes it.
R=jkummerow@chromium.org
Bug: v8:9919
Change-Id: I3b7612d90b0577f2763c5ab70c34eeb11307657b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1899607
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64761}
This make {LiftoffCompiler} use the new "shift by immediate" assembler
instructions. This generates shorter and faster code.
R=jkummerow@chromium.org
Bug: v8:9919
Change-Id: I49200e06edde3399a516871f43cce6a9ff5b8d7b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1899606
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64759}
In fact, shifts are used most often with a fixed shift amount. This CL
adds special handling for this in Liftoff, to generate shorter and
faster code.
R=jkummerow@chromium.org
Bug: v8:9919
Change-Id: I9629872b628e0d617af00143ea27f9fbe95cb21e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1897539
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64758}
This removes the usage of retaining_path_mode template parameter in
main thread marking visitor and makes the incremental visitor
identical to the stop-the-world visitor.
Subsequent CL will switch these visitors to MarkingVisitorBase.
Bug: chromium:1019218
Change-Id: I00e3ef190d8f2ac821cb63b02c402aad5ea49e9c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1897538
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64757}
Since flags are statically stored, there's no difference between
the first runs and the second last run in stress-opt mode. This
simplifies the code to account for that.
Bug: v8:9940
Change-Id: Icc978f20476c0dffb084f7e9e6a200a5608e3515
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1898659
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64756}
The function has a single call only, so inline it there.
R=jkummerow@chromium.org
Change-Id: I7beeefa6e54aa2a85389fd5df33c08b8a5126de6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895563
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64754}
port 4664840https://crrev.com/c/1871605
Original Commit Message:
CallDebugOnFunctionCall was always using Registers and not Immediates.
Then ParameterCount is not really needed. Since updating that, we
could update other functions, e.g InvokeFunction, to only use
registers too.
Also removed now irrelevant variables, e.g definitely_mismatches.
[mips][codegen] Removed ParameterCount class
port 1e69689https://crrev.com/c/1886916
Original Commit Message:
It was used only with Register inputs, so we can replace its uses with
the Registers themselves.
Change-Id: I0a661519f5602bf4d52c40c6c238436b93b71664
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1898826
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64753}
These are two of the remaining missing instructions from the MVP.
This CL adds support to {LiftoffCompiler} and provides assembly
implementations for ia32, x64, arm, and arm64.
R=jkummerow@chromium.org
Bug: v8:9919
Change-Id: I4d00d2030e1c5c03ee3afaa536697d3847e26ef0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893343
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64752}
This reverts commit d4574d186f.
Reason for revert: In addition to the earlier octane regression, this cl also created a regression in desktop browsing
Bug: chromium:1019601
Original change's description:
> Reland "[regexp] Clone match info for match indices."
>
> This reverts commit d7793c0684.
>
> Reason for revert: This cl *will* cause regexp regressions. We are trying to gauge the real world impact.
>
> Original change's description:
> > Revert "[regexp] Clone match info for match indices."
> >
> > This reverts commit dfd9ceb984.
> >
> > Reason for revert: Regressions https://chromeperf.appspot.com/group_report?rev=64356https://crbug.com/1015749
> >
> > Original change's description:
> > > [regexp] Clone match info for match indices.
> > >
> > > The current behavior for generating match indices simply stashes a
> > > pointer to the match info and then constructs the indices lazily.
> > > However, it turns out the match info object used to create the result
> > > object is the regexp_last_match_info living on native context, and thus
> > > it can change between the creation of the result object and the generation
> > > of indices. This cl clones the match info which will be safer.
> > >
> > > Bug: v8:9548
> > > Change-Id: Ia6f26f88fbc22fd09671bf4c579d39a1510b552d
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864585
> > > Commit-Queue: Joshua Litt <joshualitt@chromium.org>
> > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#64356}
> >
> > TBR=jgruber@chromium.org,joshualitt@chromium.org
> >
> > # Not skipping CQ checks because original CL landed > 1 day ago.
> >
> > Bug: v8:9548, chromium:1015749
> > Change-Id: I9c30b8fb459cf2aa89d920bf061614441250844d
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1870236
> > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#64407}
>
> TBR=jgruber@chromium.org,joshualitt@chromium.org
>
>
> Bug: v8:9548, chromium:1015749
> Change-Id: I151511307e3d8752fdbde4b8247514031b141b08
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879587
> Reviewed-by: Joshua Litt <joshualitt@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Joshua Litt <joshualitt@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64587}
TBR=jgruber@chromium.org,joshualitt@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:9548, chromium:1015749
Change-Id: Ie5a8e55338728aae33102d82e60a188f6440e8f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1898030
Reviewed-by: Joshua Litt <joshualitt@chromium.org>
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64749}
This reverts commit 54379af9b0.
Reason for revert: Big performance regressions, need to investigate
Original change's description:
> [wasm] Remove fixed limit on number of background tasks
>
> After fixing https://crbug.com/v8/8916, background compilation scales
> far beyond 10 threads, especially for TurboFan (where much more work is
> parallelizable). Thus, remove the limit of 10 background compilation
> tasks, and use all available threads instead.
>
> R=mstarzinger@chromium.org
>
> Bug: v8:8916
> Change-Id: I13c30777e3c85b2de7901b5eac3e6a41457a56f9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893348
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64724}
TBR=mstarzinger@chromium.org,clemensb@chromium.org
Change-Id: I180cff9f39d8960aa793f279cfb61b7444992bc6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8916
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1897889
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64748}
Before this change large fixed arrays were visited in chunks of 32KB
on the main thread. Now large fixed arrays are divided into chunks
of kMaxRegularHeapObjectSize, which is consistent with large fixed
array processing on concurrent threads and make more sense considering
that regular fixed arrays are visited in one go.
Bug: chromium:1019218
Change-Id: I0c6d9c6c7d1db7f6a75d282601b73d4819b30e80
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1897886
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64746}
This makes WebAssembly runtime stubs use Smi encoding for parameters in
instead of a HeapNumber encoding whenever possible. This potentially
avoids allocating on the GC'ed heap.
R=clemensb@chromium.org
Change-Id: Ie37c3005442748d9bd71da59a2c11d103a65fe9c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895574
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64745}
Change builtin calls in wasm-compiler.cc to use CallBuiltinPointer
rather than CallCodeObject which means they bypass the trampoline.
Since the Code objects are no longer being called, remove them from the
executable Code object allow-list in builtins.cc.
Bug: v8:9338
Change-Id: I9835bab859c4d5e45dbfb4c7a339ccf74e719237
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893337
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64744}
This makes the stop-the-world marking visitor the same as incremental
visitor for processing large fixed arrays.
Bug: chromium:1020982
Change-Id: Ie3b4ea7ad397ea0ae00000875aca0d142f672a3f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1897828
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64743}
We'll remove the file from Chromium in a follow up after V8 has rolled
+ 2 days.
Bug: v8:9911
Change-Id: I69fe56855f1ba83bec0d39e0fb6acb7e4182c6b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1897826
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64742}
Port 352bbb1279
Original Commit Message:
This is a reland of 855591a54d
Fixes break in builds that verify ReadOnlyHeap by relaxing the requirement for
Code objects to be in CODE_SPACE in PagedSpaceObjectIterator::FromCurrentPage.
Original change's description:
> Reland: [builtins] Move non-JS linkage builtins code objects into RO_SPACE
>
> Reland of https://chromium-review.googlesource.com/c/v8/v8/+/1795358.
>
> [builtins] Move non-JS linkage builtins code objects into RO_SPACE
>
> Creates an allow-list of builtins that can still go in code_space
> including all TFJ builtins and a small manual list that should be pared
> down in the future.
>
> For builtins that go in RO_SPACE a Code object is created that contains an
> immediate trap instruction. Generally these Code objects are still no
> smaller than CODE_SPACE Code objects because of the Code object alignment
> requirements. This will hopefully be addressed in a follow-up CL either by
> relaxing them or removing the instruction stream completely.
>
> In the snapshot, this reduces code_space from ~152k to ~40k (-112k) and
> increases by the same amount.
>
> Change-Id: I76661c35c7ea5866c1fb16e87e87122b3e3ca0ce
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893336
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64700}
R=delphick@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: If150434119828a87e295b0639c934392812bb345
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1896904
Reviewed-by: Milad Farazmand <miladfar@ca.ibm.com>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#64741}
Now that embedded builtins are mandatory and non-embedded builtins no
longer need to be supported, it is safe to embed the target of the
CEntry builtin directly into the {WasmCompileLazy} builtin. This just
uses the regular {MacroAssembler::CallRuntime} functionality now.
R=clemensb@chromium.org
Change-Id: Id09e73e96cc43fe019c837b9cc42df441c6aada0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895571
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64740}
Now that embedded builtins are mandatory and non-embedded builtins no
longer need to be supported, it is safe to embed the target of the
CEntry builtin directly into WebAssembly runtime stubs. This produces
more efficient code and simplifies the runtime stubs.
R=clemensb@chromium.org
Change-Id: If2f91fa733edc266af3a204ac17ff36e4c0b41a3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895567
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64739}
This issue was fixed in https://chromium-review.googlesource.com/c/v8/v8/+/1873692
Bug: chromium:1016450
Change-Id: I56e1c504ae6876283568a88a9aa7d24af3ba6474
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876057
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64738}
This simplifies how WebAssembly runtime stubs call other builtins.
Instead of loading the {AllocateHeapNumber} builtin from the instance,
we can now embed its direct functionality since builtins are always
independent of the Isolate by now.
R=delphick@chromium.org
Change-Id: Ieb22e9406aa825e84482acc82619a33821a43758
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895565
Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64737}
There seems to be a bug in Python versions prior
to 2.7.9 where running exec could produce the following error:
SyntaxError: unqualified exec is not allowed in function
'_ParsePythonTestTemplates' it contains a nested function
with free variables (testcfg.py, line 71)
https://bugs.python.org/issue21591
It's causing an issue on all Ubuntu 14 and RHEL 7 machines.
The proposed change is an equivalent syntax which doesn't
produce an error:
https://docs.python.org/2/reference/simple_stmts.html#the-exec-statement
Change-Id: I159cc1be58ff375f313ae5c4fb814763704b880e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893647
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#64736}
This CL adds V8_EXPORT_PRIVATE declarations needed for component build with
enabled MSAN on Linux.
Change-Id: Ia79ca117b8f5128f8e681b0574066e86f2407a84
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893342
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64735}
Changing the target of JSCall nodes (e.g. while lowering higher order calls)
now preserves feedback and speculation mode to allow further (speculative)
optimizations. A flag is introduced to mark feedback unrelated to the call
target after such a transformation. This flag is used to prevent access to
the feedback without the need to invalidate it.
Bug: v8:9702
Change-Id: I311d3a4b1b22d6f65e5837a23b0b7585c8d75eed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1844788
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64733}
Relevant opcodes:
* kFrameState
* kStateValues
* kTypedStateValues
The code to decompress CompressedHeapConstants is not there for the
opcodes stated above. We can only do this optimization for Loads
for the moment.
Bug: v8:7703
Change-Id: I226089f1b2b78d0bd742785c7c9924284a97c72d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879942
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64732}
This is a reland of 855591a54d
Fixes break in builds that verify ReadOnlyHeap by relaxing the requirement for
Code objects to be in CODE_SPACE in PagedSpaceObjectIterator::FromCurrentPage.
Original change's description:
> Reland: [builtins] Move non-JS linkage builtins code objects into RO_SPACE
>
> Reland of https://chromium-review.googlesource.com/c/v8/v8/+/1795358.
>
> [builtins] Move non-JS linkage builtins code objects into RO_SPACE
>
> Creates an allow-list of builtins that can still go in code_space
> including all TFJ builtins and a small manual list that should be pared
> down in the future.
>
> For builtins that go in RO_SPACE a Code object is created that contains an
> immediate trap instruction. Generally these Code objects are still no
> smaller than CODE_SPACE Code objects because of the Code object alignment
> requirements. This will hopefully be addressed in a follow-up CL either by
> relaxing them or removing the instruction stream completely.
>
> In the snapshot, this reduces code_space from ~152k to ~40k (-112k) and
> increases by the same amount.
>
> Change-Id: I76661c35c7ea5866c1fb16e87e87122b3e3ca0ce
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893336
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64700}
Change-Id: I4eeb7dab3027b42fa58c5dfb2bad9873e9fff250
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893192
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64728}
Add a new LargeObjectSpace for off-thread allocation. Similar to the
paged OffThreadSpace, it always allocates pages, doesn't participate
in mark or sweep, and can be merged into the OldLargeObjectSpace once
its objects are ready.
Bug: chromium:1011762
Change-Id: I95e2d38b10a9cc5eae4ffd35afef95272e13c731
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1881153
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64727}
PR wasn't defined correctly and it was causing issues.
Added prettify to the npm packages, and removed the (not needed)
explicit prettify.css.
Bug: v8:7327
Change-Id: Ieb8999d63df6764354dd628516e0ed9270b8a862
Notry: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893344
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64726}
After fixing https://crbug.com/v8/8916, background compilation scales
far beyond 10 threads, especially for TurboFan (where much more work is
parallelizable). Thus, remove the limit of 10 background compilation
tasks, and use all available threads instead.
R=mstarzinger@chromium.org
Bug: v8:8916
Change-Id: I13c30777e3c85b2de7901b5eac3e6a41457a56f9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893348
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64724}
Moves all of the KeyedSloppyArguments functions out of CodeStubAssembler
and into builtins-handler-gen.cc which is the only place they're used.
Bug: v8:9810
Change-Id: Ie52bdf24b7890943b89007f566dd18fe644a5996
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895558
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64723}
This re-enables verification for RO_SPACE when V8_SHARED_RO_HEAP is
defined. This required refactoring PagedSpaceObjectIterator and methods
in its calling chain to explicitly pass the PagedSpace and Heap pointers
through as they cannot be obtained from the Page in this mode.
Also removes unused Page::Print() method.
Bug: v8:7464
Change-Id: Ibc2c147a7bde6723f43bbaf93cf1db93e76c611e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893350
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64722}
This CL improves reporting for WeakMap entries: If a retaining chain
goes through a WeakMap entry (i.e. key and weak map are alive, and keep
value alive) then both the key and the value are reported. Additionally
the phrasing is clarified, such that entries in retaining paths are
easier to understand.
Bug: chromium:1020096
Change-Id: Ib05cd6f7939c6de41b554c682ad1fbf685b87608
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893335
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64721}
This fixes a compilation error in Node.js with Xcode:
initialize the const member 'blueprint_'.
error: constructor for 'v8::internal::compiler::Callee' must explicitly
Change-Id: Ia55398428d0de35a9ad5132eabd22d0adb694514
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895561
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64719}
Port b875f4661a
Original Commit Message:
Reland "[compiler] Optionally apply an offset to stack checks"
This is a reland of 4a16305b65
The original CL adjust only one part of the stack check, namely the
comparison of the stack pointer against the stack limit in generated code.
There is a second part: Runtime::kStackGuard repeats this check to
distinguish between a stack overflow and an interrupt request.
This second part in runtime must apply the offset just like in generated
code. It is implemented in this reland by the StackCheckOffset operator
and a new StackGuardWithGap runtime function.
Original change's description:
> [compiler] Optionally apply an offset to stack checks
>
> The motivation behind this change is that the frame size of an optimized
> function and its unoptimized version may differ, and deoptimization
> may thus trigger a stack overflow. The solution implemented in this CL
> is to optionally apply an offset to the stack check s.t. the check
> becomes 'sp - offset > limit'. The offset is applied to stack checks at
> function-entry, and is set to the difference between the optimized and
> unoptimized frame size.
>
> A caveat: OSR may not be fully handled by this fix since we've already
> passed the function-entry stack check. A possible solution would be to
> *not* skip creation of function-entry stack checks for inlinees.
>
> This CL: 1. annotates stack check nodes with the stack check kind, where
> kind is one of {function-entry,iteration-body,unknown}. 2. potentially
> allocates a temporary register to store the result of the 'sp - offset'
> in instruction selection (and switches input registers to 'unique'
> mode). 3. Applies the offset in code generation.
>
> mode). 3. Applies the offset in code generation.
>
> Drive-by: Add src/compiler/globals.h for compiler-specific globals.
>
> Bug: v8:9534,chromium:1000887
> Change-Id: I257191c4a4978ccb60cfa5805ef421f30f0e9826
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762521
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63701}
Change-Id: I77554bddde57153ec92c4b80c15d0a52efbaab2d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893554
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Mu Tao <pamilty@gmail.com>
Cr-Commit-Position: refs/heads/master@{#64718}
Currently atomic operations are only allowed on shared WebAssembly.memory.
An attempt to use atomic operations otherwise is a validation failure, there
is an ongoing attempt to allow Wasm atomic operations on any memory object.
https://github.com/WebAssembly/threads/issues/144
This CL adds experimental support for allowing atomic operations on all
memory objects behind the --wasm-atomics-on-non-shared-memory flag. Note
that Wait/Notify may not work as expected as they have additional checks
to ensure that the memory is a SAB.
Bug: v8:9921
Change-Id: Ia65b1a4a96ec026430fcce028465423f600adacd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895703
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64716}
