Includes various fixes and cleanups here and there.
Bug: v8:7703, v8:8852
Change-Id: I603eb0212cab3fecabfa15dceb70ee23b81cdb5a
Reviewed-on: https://chromium-review.googlesource.com/c/1491595
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59909}
Currently each isolate stores its own array of
{CallInterfaceDescriptorData}. This array has size 173, and each entry
has 40 bytes. That's already 7kB per isolate.
Additionally, each {CallInterfaceDescriptorData} allocates two
heap-allocated arrays, which probably add up to more than the static
size of the {CallInterfaceDescriptorData}. Note that all the
{CallInterfaceDescriptorData} instances are initialized eagerly on
isolate creation.
Since {CallInterfaceDescriptor} is totally isolate independent itself,
this CL refactors the current design to avoid a copy of them per
isolate, and instead shares them process-wide. Still, we need to free
the allocated heap arrays when the last isolate dies to avoid leaks.
This can probably be refactored later by statically initializing more
and avoiding the heap allocations all together.
This refactoring will also allow us to use {CallInterfaceDescriptor}s
from wasm background compilation threads, which are not bound to any
isolate.
R=mstarzinger@chromium.org, titzer@chromium.org
Bug: v8:6600
Change-Id: If8625b89951eec8fa8986b49a5c166e874a72494
Reviewed-on: https://chromium-review.googlesource.com/1100879
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53803}
The idea is to mark all the branches and loads participating in array
bounds checks, and let them contribute-to/use the poisoning register.
In the code, the marks for array indexing operations now contain
"Critical" in their name. By default (--untrusted-code-mitigations),
we only instrument the "critical" operations with poisoning.
With that in place, we also remove the array masking approach based
on arithmetic.
Since we do not propagate the poison through function calls,
we introduce a node for poisoning an index that is passed through
function call - the typical example is the bounds-checked index
that is passed to the CharCodeAt builtin.
Most of the code in this CL is threads through the three levels of
protection (safe, critical, unsafe) for loads, branches and flags.
Bug: chromium:798964
Change-Id: Ief68e2329528277b3ba9156115b2a6dcc540d52b
Reviewed-on: https://chromium-review.googlesource.com/995413
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52883}
This CL changes the poisoning in the interpreter to use the
infrastructure used in the JIT.
This does not change the original flag semantics:
--branch-load-poisoning enables JIT mitigations as before.
--untrusted-code-mitigation enables the interpreter mitigations
(now realized using the compiler back-end), but does not enable
the back-end based mitigations for the Javascript JIT. So in effect
--untrusted-code-mitigation makes the CSA pipeline for bytecode handlers
use the same mechanics (including changed register allocation) that
--branch-load-poisoning enables for the JIT.
Bug: chromium:798964
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27
Reviewed-on: https://chromium-review.googlesource.com/928881
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52243}
The macro list avoids duplication in external-reference-table and will
allow us to statically determine the size of the table in a follow-up.
TBR=mlippautz@chromium.org
Bug: v8:6666
Change-Id: I06bb2e8c25970b3c1047dafd6c63d7ca291fe37e
Reviewed-on: https://chromium-review.googlesource.com/956187
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51850}
This is preparatory cleanup work for eventually tracking the functions
(rather than concrete closures) in the CALL_IC, also for builtins like
the default PromiseCapability [[Resolve]] and [[Reject]] functions. It
adds a new FeedbackCell type, which is used by JSFunctions consistently
now to reference the feedback vector (or undefined if not the function
is not compiled yet or is a native/asm.js function).
This also changes the calling convention for FastNewClosure builtin and
the JSCreateClosure operator in TurboFan to carry the FeedbackCell here
instead of the parent FeedbackVector and the slot index. In addition we
eliminate the now unused %InterpreterNewClosure runtime function.
Bug: v8:2206, v8:7253, v8:7310
Change-Id: Ib4ce456e276e0273e57c163dcdd0b33abf863656
Reviewed-on: https://chromium-review.googlesource.com/928403
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51474}
Moves generation of speculation poison to be based on the PC target vs the
actual PC being executed. The speculation poison is generated in the prologue
of the generated code if CompilationInfo::kGenerateSpeculationPoison is set.
The result is stored in a known register, which can then be read using the
SpeculationPoison machine node.
Currently we need to ensure the SpeculationPoison node is scheduled right after
the code prologue so that the poison register doesn't get clobbered. This is
currently not verified, however it's only use is in RawMachineAssembler where
it is manually scheduled early.
The Ignition bytecode handlers are updated to use this speculation poison
rather than one generated by comparing the target bytecode.
BUG=chromium:798964
Change-Id: I2a3d0cfc694e88d7a8fe893282bd5082f693d5e2
Reviewed-on: https://chromium-review.googlesource.com/893160
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51229}
This patch normalizes the casing of hexadecimal digits in escape
sequences of the form `\xNN` and integer literals of the form
`0xNNNN`.
Previously, the V8 code base used an inconsistent mixture of uppercase
and lowercase.
Google’s C++ style guide uses uppercase in its examples:
https://google.github.io/styleguide/cppguide.html#Non-ASCII_Characters
Moreover, uppercase letters more clearly stand out from the lowercase
`x` (or `u`) characters at the start, as well as lowercase letters
elsewhere in strings.
BUG=v8:7109
TBR=marja@chromium.org,titzer@chromium.org,mtrofin@chromium.org,mstarzinger@chromium.org,rossberg@chromium.org,yangguo@chromium.org,mlippautz@chromium.org
NOPRESUBMIT=true
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I790e21c25d96ad5d95c8229724eb45d2aa9e22d6
Reviewed-on: https://chromium-review.googlesource.com/804294
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49810}
Contributed by kanghua.yu@intel.com.
Bug: None
Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9
Reviewed-on: https://chromium-review.googlesource.com/604648
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Pan Deng <pan.deng@intel.com>
Cr-Commit-Position: refs/heads/master@{#47968}
This change adapts the Call bytecode handlers such that they don't require
a stack frame. It does this by modifying the call bytecode handler to
tail-call the Call or InterpreterPushArgsAndCall builtins. As a result, the
callee function will return to the InterpreterEntryTrampoline when it returns
(since this is the return address on the interpreter frame), which is
adapted to dispatch to the next bytecode handler. The return bytecode
handler is modified to tail-call a new InterpreterExitTramoline instead
of returning to the InterpreterEntryTrampoline.
Overall this significanlty reduces the amount of stack space required for
interpreter frames, increasing the maximum depth of recursive calls from
around 6000 to around 12,500 on x64.
BUG=chromium:753705
Change-Id: I23328e4cef878df3aca4db763b47d72a2cce664c
Reviewed-on: https://chromium-review.googlesource.com/634364
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47617}
The tail call implementation is hidden behind the --harmony-tailcalls
flag, which is off-by-default (and has been unstaged since February).
It is known to be broken in a variety of cases, including clusterfuzz
security issues (see sample Chromium issues below). To avoid letting
the implementation bitrot further on trunk, this patch removes it.
Bug: v8:4698, chromium:636914, chromium:724746
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I9cb547101456a582374fdf7b1a3f044a9ef33e5c
Reviewed-on: https://chromium-review.googlesource.com/569069
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46651}
Unfortunately, even for an empty generator, we still use 8 register for various things (try-finally, copies of generator object, parser-introduced temporaries). I will try to get rid of these in separate CLs.
Changes:
- SuspendGenerator bytecode now takes register list to save.
- ResumeGenerator was split into two bytecodes:
* Resume generator reads the state out and marks the generator as
'executing'.
* RestoreGeneratorRegisters reloads the registers from
the generator.
+ this required adding support for output register list.
- Introduced generator_object_ register in the bytecode generator.
* in subsequent CLs, I will make better use of it, the goal is
to get rid if the .generator_object local variable.
- Taught register optimizer to flush unassigned registers.
BUG=v8:6379
Review-Url: https://codereview.chromium.org/2894293003
Cr-Commit-Position: refs/heads/master@{#45675}
Adds a collection of call bytecodes which have an implicit undefined
receiver argument, for cases such as global calls where we know that the
receiver has to be undefined. This way we can skip an LdaUndefined,
decrease bytecode register pressure, and set a more accurate
ConvertReceiverMode on the interpreter and TurboFan call.
As a side effect, the "normal" Call bytecode now becomes a rare case
(only with calls and super property calls), so we get rid of its 0-2
argument special cases and modify CallProperty[N] to use the
NotNullOrUndefined ConvertReceiverMode.
Reland of https://chromium-review.googlesource.com/c/463287 after fixing
tests in https://codereview.chromium.org/2813873002.
Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5
Reviewed-on: https://chromium-review.googlesource.com/474752
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44582}
This reverts commit 751e893591.
Reason for revert: Breaks layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/14885
See:
https://github.com/v8/v8/wiki/Blink-layout-tests
Original change's description:
> [ignition] Add call bytecodes for undefined receiver
>
> Adds a collection of call bytecodes which have an implicit undefined
> receiver argument, for cases such as global calls where we know that the
> receiver has to be undefined. This way we can skip an LdaUndefined,
> decrease bytecode register pressure, and set a more accurate
> ConvertReceiverMode on the interpreter and TurboFan call.
>
> As a side effect, the "normal" Call bytecode now becomes a rare case
> (only with calls and super property calls), so we get rid of its 0-2
> argument special cases and modify CallProperty[N] to use the
> NotNullOrUndefined ConvertReceiverMode.
>
> Change-Id: I9374a32fefd66fc0251b5193bae7a6b7dc31eefc
> Reviewed-on: https://chromium-review.googlesource.com/463287
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#44530}
TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org,v8-reviews@googlegroups.com,v8-mips-ports@googlegroups.com,v8-ppc-ports@googlegroups.com,v8-x87-ports@googlegroups.com,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I7629dec609d0ec938ce7105d6c1c74884e5f9272
Reviewed-on: https://chromium-review.googlesource.com/474744
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44548}
Adds a collection of call bytecodes which have an implicit undefined
receiver argument, for cases such as global calls where we know that the
receiver has to be undefined. This way we can skip an LdaUndefined,
decrease bytecode register pressure, and set a more accurate
ConvertReceiverMode on the interpreter and TurboFan call.
As a side effect, the "normal" Call bytecode now becomes a rare case
(only with calls and super property calls), so we get rid of its 0-2
argument special cases and modify CallProperty[N] to use the
NotNullOrUndefined ConvertReceiverMode.
Change-Id: I9374a32fefd66fc0251b5193bae7a6b7dc31eefc
Reviewed-on: https://chromium-review.googlesource.com/463287
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44530}
Before this patch, the registers needed for bytecode dispatch in interpreter
handlers were inconsistently stored in the interpreter frame and/or kept in
values that remained live across calls.
After this patch, these registers are explicitly reloaded after calls, making it
possible to elide the spills of those registers before the call in many cases.
Some highlights from the CL:
* Added methods to the CSA and InterpreterAssembler to efficiently store and
load Smis values and Smi interpreter registers on x64 without explicit
tagging/untagging.
* Created Variables for all of the interpreter-internal values that need to be
reloaded before bytecode dispatch at the end of an interpreter handler.
* The bytecode offset can be written out early in a handler by marking it
has having a call along it's critical path. By moving this early in a
handler, it becomes possible to use memory operands for pushes used to
marshall parameters when making calls.
Change-Id: Icf8d7798789f88a4489e06a7092616bbbb881577
Reviewed-on: https://chromium-review.googlesource.com/442566
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43260}
... and TypeFeedbackMetadata to FeedbackMetadata.
BUG=
Change-Id: I2556d1c2a8f37b8cf3d532cc98d973b6dc7e9e6c
Reviewed-on: https://chromium-review.googlesource.com/439244
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#42999}
TypeFeedbackVectors are strongly rooted by a closure. However, in modern
JavaScript closures are created and abandoned more freely. An important
closure may not be present in the root-set at time of garbage collection,
even though we've cached optimized code and use it regularly. For
example, consider leaf functions in an event dispatching system. They may
well be "hot," but tragically non-present when we collect the heap.
Until now, we've relied on a weak root to cache the feedback vector in
this case. Since there is no way to signal intent or relative importance,
this weak root is as susceptible to clearing as any other weak root at
garbage collection time.
Meanwhile, the feedback vector has become more important. All of our
ICs store their data there. Literal and regex boilerplates are stored there.
If we lose the vector, then we not only lose optimized code built from
it, we also lose the very feedback which allowed us to create that optimized
code. Therefore it's vital to express that dependency through the root
set.
This CL does this by creating a strong link to a feedback
vector at the instantiation site of the function closure.
This instantiation site is in the code and feedback vector
of the outer closure.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2674593003
Cr-Commit-Position: refs/heads/master@{#42953}
They have the same lifetime. It's a match!
Both structures are native context dependent and dealt with (creation,
clearing, gathering feedback) at the same time. By treating the spaces used
for literal boilerplates as feedback vector slots, we no longer have to keep
track of the materialized literal count elsewhere.
A follow-on CL removes even more parser infrastructure related to this count.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2655853010
Cr-Commit-Position: refs/heads/master@{#42771}
We can share almost all of the architecture-specific builtin code with super-call-with-spread.
Info to port-writers: The code in CheckSpreadAndPushToStack has changed slightly from what was in Generate_ConstructWithSpread, in that we take the length of the spreaded parameters from the JSArray rather than the FixedArray backing store.
BUG=v8:5511
Review-Url: https://codereview.chromium.org/2649143002
Cr-Commit-Position: refs/heads/master@{#42632}
This is in preparation for introducing more specialized
CodeStubAssembler subclasses. The state object can be handed
around, while the Assembler instances are temporary-scoped.
BUG=v8:5628
Original review: https://codereview.chromium.org/2498073002/
Review-Url: https://codereview.chromium.org/2502293002
Cr-Commit-Position: refs/heads/master@{#41028}
Reason for revert:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20shared doesn't want to compile. Missing export annotation?
Original issue's description:
> [refactoring] Split CodeAssemblerState out of CodeAssembler
>
> This is in preparation for introducing more specialized
> CodeStubAssembler subclasses. The state object can be handed
> around, while the Assembler instances are temporary-scoped.
>
> BUG=v8:5628
TBR=ishell@chromium.org,mstarzinger@chromium.org,jkummerow@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5628
Review-Url: https://codereview.chromium.org/2504913002
Cr-Commit-Position: refs/heads/master@{#41018}
This is in preparation for introducing more specialized
CodeStubAssembler subclasses. The state object can be handed
around, while the Assembler instances are temporary-scoped.
BUG=v8:5628
Review-Url: https://codereview.chromium.org/2498073002
Cr-Commit-Position: refs/heads/master@{#41015}
The existing Load/StoreContextElement operations take the index as an int. This
CL adds versions that take the index as a Node. These already existed in the
interpreter-assembler, from which they are now removed.
R=mstarzinger@chromium.org, rmcilroy@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2473003004
Cr-Commit-Position: refs/heads/master@{#40810}
This allows people writing code stubs to just verify the graph of the stub they're working on, at least until we fix all of the issues we have and enable the verification by default.
Also fixes representations in CodeStubAssembler::SmiOr and InterpreterAssembler::StarDispatchLookahead.
R=bmeurer@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2413653006
Cr-Commit-Position: refs/heads/master@{#40320}
They are nops, but will be used when verifying the machine graph.
BUG=
Review-Url: https://codereview.chromium.org/2367413002
Cr-Commit-Position: refs/heads/master@{#39758}
This is a first step towards a perfect world where a call interface descriptor is the only place that defines calling convention for a particular code stub.
Review-Url: https://codereview.chromium.org/2172223002
Cr-Commit-Position: refs/heads/master@{#38059}
For some bytecodes it is beneficial to always look for a Star
bytecode when dispatching to the next and inline perform it
without dispatching to the Star handler.
BUG=v8:4280
LOG=N
Review-Url: https://codereview.chromium.org/2142273003
Cr-Commit-Position: refs/heads/master@{#37904}
Make intrinsic ids a contiguous set of ids so that the switch statement can build
a table switch rather than doing a large if/else tree.
BUG=v8:4822
LOG=N
Review-Url: https://codereview.chromium.org/2084623002
Cr-Commit-Position: refs/heads/master@{#37135}
We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.
BUG=
Review-Url: https://codereview.chromium.org/1906823002
Cr-Commit-Position: refs/heads/master@{#36539}
