Just to ensure this is portable across all platforms.
Credits go to https://github.com/graphitemaster/incbin, bits of the
.incbin code were taken from there. Thanks!
Bug: v8:6666
Change-Id: Id068f70fb4ac925b574a14dec40cf80627a22073
Reviewed-on: https://chromium-review.googlesource.com/881181
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50883}
This adds support for the rest of the i32 comparisons.
R=titzer@chromium.org
Bug: v8:6600
Change-Id: Ic613c59d17140b1e5c72fb58c4a8487ae13b6ae6
Reviewed-on: https://chromium-review.googlesource.com/887022
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50881}
Replace conversions of relative indices in builtin-string-gen.cc with
ConvertToRelativeIndex which is defined in code-stub-assembler.cc.
Change-Id: I790d58d296ccb482d3f96a62ec64227b1c2ce2c0
Reviewed-on: https://chromium-review.googlesource.com/883701
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50880}
A timeout result of randomly combined tests is not a useful indicator.
Therefore we ignore those now. This also prevents timeouts from being
re-run.
TBR=sergiyb@chromium.org
NOTRY=true
Bug: v8:6917
Change-Id: I8e5eb93e2f13067ca5270fb152c3dc1eda1bb3c2
Reviewed-on: https://chromium-review.googlesource.com/888559
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50879}
which was dropped from the proposal:
https://github.com/tc39/proposal-bigint/pull/101
Bug: v8:6791
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I5a3e0024900b34a322a23bcbc4bfdbdffbf8b9d4
Reviewed-on: https://chromium-review.googlesource.com/885510
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50877}
For M65 I added a fast-path for String.p.charCodeAt, which behaves
incorrectly for wide characters. This patch disables the incorrect
fast-path. This is likely no performance regression against M64,
as M64 did not have a fast path for String.p.charCodeAt.
Bug: v8:7371
Change-Id: I8ea9c5da5a583138d87ccb8ffe6d61eba16630b9
Reviewed-on: https://chromium-review.googlesource.com/886782
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50873}
This is somewhat of a revival of what used to be
UnseededNumberDictionary. The difference to NumberDictionary is that
each entry only has two fields (no field for property details) and there
is no header field for a bitfield.
The reason for this change is memory regression introduced when we
removed UnseededNumberDictionary (6e1c57eaa9). We now use
SimpleNumberDictionary for
- slow template instantiation cache
- code stubs table
- value serializer map
- stack frame cache
- type profile source positions
R=ishell@chromium.org, ulan@chromium.org
Bug: chromium:783695
Change-Id: I3cd32e485060bb379fb2279eeefbbbded7455f0e
Reviewed-on: https://chromium-review.googlesource.com/885811
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50869}
Also refactor the implementation of i32.eqz such that the same
platform-specific code can be reused.
As a next step, it should be straight-forward to add other i32
comparison operations.
R=titzer@chromium.org
Bug: v8:6600
Change-Id: I4e8768d4ceb7294ba35777b7777ddd69d1a58cf1
Reviewed-on: https://chromium-review.googlesource.com/877889
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50868}
- Introduce new helper IsFastJSArrayWithNoCustomIteration.
- Consolidates all entry array checks...
- Is a fast array (defers to BranchIfFastJSArray)
- No possibility that the Array's iteration protocol has been tampered with
- Introduce new BoolT constant helpers Int32TrueConstant and Int32FalseConstant.
Bug: chromium:804176, chromium:804188
Change-Id: I6b08396484682dc680b431ea564a7a28eeab8108
Reviewed-on: https://chromium-review.googlesource.com/883065
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50867}
In addition I added some comments in the update script which describes
steps which have to be takes the first time you run the script on a
new machine.
R=titzer@chromium.org
Change-Id: Ib360e6fcdcb63eaf225f398eff60041b48f86b62
Reviewed-on: https://chromium-review.googlesource.com/883344
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50863}
We cannot handle i64 values yet, so bail out if an indirect call
returns i64. The same bailout already exists for direct calls.
R=ahaas@chromium.org
Bug: v8:6600
Change-Id: I3ddf44a913ee79b5610862e3a93059c6d37a280c
Reviewed-on: https://chromium-review.googlesource.com/885813
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50862}
Bug:
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I0ecc0af1668f5036bb591e8236d9a28fba61cea5
Reviewed-on: https://chromium-review.googlesource.com/881782
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50861}
This reverts commit 181ac2b0dc.
Reason for revert: TF changes break load elimination.
Original change's description:
> [ic] Improve performance of KeyedStoreIC on literal-based arrays.
>
> In mode STORE_AND_GROW_NO_TRANSITION, the handler for elements stores
> used to bail out when seeing a COW array, even if the store that
> installed the handler had been operating on the very same array.
>
> This CL adds support for COW arrays to the mode (and renames it to
> STORE_AND_GROW_NO_TRANSITION_HANDLE_COW).
>
> Bug: v8:7334
> Change-Id: I6a15e8c1ff8d4ad4d5b8fc447745dce5d146c67c
> Reviewed-on: https://chromium-review.googlesource.com/876014
> Commit-Queue: Georg Neis <neis@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50840}
TBR=neis@chromium.org,ishell@chromium.org,bmeurer@chromium.org
Change-Id: Id841d91b12d199045e0a9c4ddae2c2ead20b5e21
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7334
Reviewed-on: https://chromium-review.googlesource.com/885814
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50860}
Refactor the PromiseHandle builtin and move the separate debug checks
into the PromiseHookBefore and PromiseHookAfter runtime calls, so they
are performed only when we've already hit the slow-path.
Bug: v8:7253
Change-Id: I01ab8592a474b6897280734b995cab0b90a5e010
Reviewed-on: https://chromium-review.googlesource.com/884583
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50856}
Do not start a new step when an existing step is in progress. We may
have partially updated information as part of the current step, and the
next step will assume consistency. A new step will be started once the
current in-progress step completes.
BUG=v8:7313
Change-Id: I4c0c47c4f4b5f8b9139be24408440189679b38dc
Reviewed-on: https://chromium-review.googlesource.com/882507
Reviewed-by: Ali Ijaz Sheikh <ofrobots@google.com>
Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com>
Cr-Commit-Position: refs/heads/master@{#50855}
When moving arguments for calls into the right registers and stack
slots, we were sometimes overwriting stack slots which would still be
used later to load arguments from. This is because we popped the (wasm)
value stack before executing the register moves, hence the stack
transfer would think the values are not being used any more and reuse
the stack slots.
With this CL, we only pop the arguments from the stack after executing
the stack transfer.
R=ahaas@chromium.org
Bug: v8:7366, v8:6600
Change-Id: I3aa5126c82634fd281959075e91e73465c39abaa
Reviewed-on: https://chromium-review.googlesource.com/883802
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50853}
This is a reland of fffa4555d0.
The win asan bots use win10 now which should fix the problems.
Original change's description:
> [build] Prepare switching win asan to 64 bits
>
> This switches the current win32 bots to win32 under the hood in MB. We'll
> remove them and replace them with win64 bots in a follow up on the infra
> side.
>
> This also infers the clang option from asan, because on windows we need
> to set clang explicitly.
>
> TBR=sergiyb@chromium.org
>
> Bug: chromium:786303
> Change-Id: I9dddd5050a21a364c302a761ff15ddd21e97c7dc
> Reviewed-on: https://chromium-review.googlesource.com/883103
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50828}
TBR=sergiyb@chromium.org
Bug: chromium:786303
Change-Id: Ie344a7b6b16f575a061d13b5c3792fc9bd862734
Reviewed-on: https://chromium-review.googlesource.com/883522
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50850}
This adds a new operator JSCreatePromise, which currently allocates
a native JSPromise instance and initializes it to pending state.
In addition to that we introduce a new PromiseHookProtector, which
get's invalidated the first time someone enables the debugger or
installs a PromiseHook (via async_hooks for example). As long as
the protector is intact we lower AsyncFunctionPromiseCreate to
JSCreatePromise and AsyncFunctionPromiseRelease to a no-op in
optimized code.
This yields a speedup of roughly 33% on the benchmark mentioned
in the bug.
Bug: v8:7271, v8:7253
Change-Id: Ib5d219f2b6e052a7cc5e6ed5aa66dd3c8885a859
Reviewed-on: https://chromium-review.googlesource.com/883124
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50849}
When executing register moves, we might need to spill registers to the
stack. Ensure that we don't exceed the reserved stack space for the
current frame.
R=ahaas@chromium.org
Bug: v8:7366, v8:6600
Change-Id: Ic11ff2ff5f46535c3663ef4cf62b095f6c8ba637
Reviewed-on: https://chromium-review.googlesource.com/883282
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50847}
The SwitchOnGeneratorState bytecode now also falls through if the
generator object is undefined (so that we don't need that jump) and
restores generator context (so that we don't need that PushContext).
This saves 10 bytes per generator.
Change-Id: Ie0872c827119b9f1d1e9244d3be6496a30cd9620
Reviewed-on: https://chromium-review.googlesource.com/867051
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50845}
The CompilationUnitBuilder of the StreamingProcessor is cleared when an
error occurs in the streaming decoder. The clearing of the
CompilationUnitBuilder was guarded by the existence of the
ModuleCompiler, because this ModuleCompiler and the
CompilationUnitBuilder are created together. However, the
CompilationUnitBuilder is reset when the next section after the code
section is processed, whereas the ModuleCompiler exists until the end of
the AsyncCompileJob. With this CL the clearing of the
CompilationUnitBuilder is also guarded by its own existence.
R=clemensh@chromium.org
Bug: chromium:805346
Change-Id: I0e9e9eaff9239fadb21c0f17990da61cbfaa6856
Reviewed-on: https://chromium-review.googlesource.com/883527
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50844}
When reserving stack space by decrementing rsp/esp, we were ignoring
the constant size needed for the stack marker and the wasm context.
Later, we were using that space anyway, which can lead to errors if e.g.
interrupt handlers kick in and use that space below rsp/esp.
R=ahaas@chromium.org
Bug: v8:7366, v8:6600
Change-Id: I2f49ef5785d33e98c29c5cf4fe7624a02e8c7628
Reviewed-on: https://chromium-review.googlesource.com/883881
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50843}
Instead of collecting eagerly compilable inner function literals (IIFEs
etc.) during AST numbering, collect them during bytecode generation,
exposing them on the CompilationJob.
Bug: v8:7178
Change-Id: I47451f412d2796e5857b4bc38c4f29c80cb0745d
Reviewed-on: https://chromium-review.googlesource.com/873872
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50842}
It is analogous to Template::SetLazyDataProperty, but for a single
existing object. Similar to how SetNativeDataProperty exists on both.
Bug: v8:7303
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I634358ee455e28150198bd87a2bd79dc59e3e449
Reviewed-on: https://chromium-review.googlesource.com/867474
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Jeremy Roman <jbroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50841}
In mode STORE_AND_GROW_NO_TRANSITION, the handler for elements stores
used to bail out when seeing a COW array, even if the store that
installed the handler had been operating on the very same array.
This CL adds support for COW arrays to the mode (and renames it to
STORE_AND_GROW_NO_TRANSITION_HANDLE_COW).
Bug: v8:7334
Change-Id: I6a15e8c1ff8d4ad4d5b8fc447745dce5d146c67c
Reviewed-on: https://chromium-review.googlesource.com/876014
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50840}
FixedArrays hanging off recursively of the constant pool without any
real objects in between can be considered as meta data. They are shared
with optimized code (embedder pointers).
Bug: v8:7266
Change-Id: I4006675e17e8eea3bdc8565254d80e2ffece0ad0
Reviewed-on: https://chromium-review.googlesource.com/883361
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50837}
This reverts commit 25ecc45f81.
Reason for revert: Two issues discovered with W^X in V8's 6.5 branch (see v8:7272 and chromium:793428). Still need a way to disable the feature.
Original change's description:
> [heap] Remove --write-protect-code-memory feature flag.
>
> R=hpayer@chromium.org
> BUG=v8:6792
>
> Change-Id: Id3413994de603dac1b7501c6fe376cdac1f9d7ce
> Reviewed-on: https://chromium-review.googlesource.com/866851
> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50759}
TBR=mstarzinger@chromium.org,hpayer@chromium.org,hablich@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:6792
Change-Id: Ie0d4409b36f22c97a6777e512618beafdef8c2f4
Reviewed-on: https://chromium-review.googlesource.com/883502
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50835}
This reverts commit bf19e60cc5.
Reason for revert: Two issues discovered with W^X in V8's 6.5 branch (see v8:7272 and chromium:793428). Still need a way to disable the feature.
Original change's description:
> [platform] Remove {PageAllocator::kReadWriteExecute}.
>
> Now that write-protection of code memory is enabled everywhere and V8 is
> fully W^X compliant, we can remove the permission mode in question.
>
> R=hpayer@chromium.org
> BUG=v8:6792
>
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: I80fe95ac6bb0e2d1ad6d993154ce45d492d941be
> Reviewed-on: https://chromium-review.googlesource.com/866855
> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50770}
TBR=bbudge@chromium.org,mstarzinger@chromium.org,hpayer@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:6792
Change-Id: If4a205497ac83084a4092560363affb13b391462
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/883461
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50834}
