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.
>
> 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}
Bug: v8:9534, chromium:1000887
Change-Id: I71771c281afd7d57c09aa48ea1b182d01e6dee2a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1822037
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64634}
{Smi::ToInt} has only one character more.
R=mstarzinger@chromium.org
Bug: v8:9810
Change-Id: I1e91bb3623a354ceeee1dc93822011a6809281d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886922
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64633}
This is the first step in unification of concurrent and main thread
marking visitors. The new MarkingVisitorBase will become a base class
for all marking visitors and will remove the existing code duplication.
This is a refactoring without behavior change.
Subsequent CL will change the main thread marking visitor to derive
from the new base class.
Bug: chromium:1019218
Change-Id: I3d47030d396e0ba6706882fbd922bbcac46181b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886920
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64632}
The macros were probably duplicated when splitting off
liftoff-assembler.cc from liftoff-compiler.cc, but are dead now.
R=mstarzinger@chromium.org
Bug: v8:9810
Change-Id: I668ce598815c45cc690653b5a12d90ab44937204
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1888070
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64631}
Start experiment with promoting all young live objects during
mark-compact. This CL sets always_promote_young_mc to true by default.
Change-Id: I306527ad2a361fc3e0edcf684c5ccec2b1d6e491
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879938
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64630}
The `capture_ix` refers to all captures while `capture_count` only
refers to named captures. Clarified by renaming `capture_count` to
`named_capture_count` and removing the incorrect part of the DCHECK.
The `>= 1` part of the condition must still hold since named captures
can only refer to explicit capture groups, which start at index 1.
Tbr: petermarshall@chromium.org
Bug: chromium:1018592
Change-Id: If8a26f6661ba0483d585f74270b3b4a3853e2ca8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886810
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64629}
Also we're not creating these any more via StringUtil in blink,
so these two helpers can go.
Change-Id: Ifdf700171ebc46cfbd6ce0af9a6f6ba73419a5a8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1887689
Auto-Submit: Johannes Henkel <johannes@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Johannes Henkel <johannes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64626}
The new API with v8::BackingStore should be used instead as explained in
https://docs.google.com/document/d/1sTc_jRL87Fu175Holm5SV0kajkseGl2r8ifGY76G35k
This also relaxes the pre-condition for [Shared]ArrayBuffer::Detach to
not require externalization first.
Bug: v8:9380, v8:9908
Change-Id: Idd119fcd28be84a2fae74ae86f7381fd997766f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859628
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64625}
Changes introduced in 30ec6a8 generates compilation error in gcc 8.1.0:
8.1.0/include/c++/bits/stl_iterator_base_funcs.h:183:2:
error: no match for 'operator--' (operand type is
'v8::internal::HandlerTable::LookupReturn(int)::Iterator')
--__i;
Which maybe caused by the following change in stl_iterator_base_funcs:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=248875
Overloading the "--" operator fixes the compilation error.
Change-Id: I32f54ddd4993375bf905996b5b1e66cd005256da
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1888190
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64624}
This flag would help customers understand why Liftoff bails out, thus
make it available also in release builds.
R=jkummerow@chromium.org
Change-Id: Ie2f69cbeaee617632f772030a3e03f052f688a10
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1888071
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64622}
There are a couple of bugs here:
1. The immediate used for vinsertps is wrong when lane == 1, the first
two bits specify which element of the source is copied, and it should
always be 00, 01 to copy the first 2 lanes of source.
2. For both cases, the second insertps call should be using dst as the
src, since dst was already updated by the first insertps call, it was
incorrectly using the old value of src. This was probably working
correctly because in many cases dst and src happened to be the same
register.
3. rep cannot be same as dst, because dst is overwritten, and rep should
stay the same
I also modified the F64x2ReplaceLane to test separately for replacing
lane 0 and lane 1.
Fixed bug 3. for arm and arm64.
Bug: v8:9728
Change-Id: Iec6e48bcfbc7d27908dd86d5f113a8b5dedd499b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1877055
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64620}
New revision: d2fc9b958e1eeb1e956f3e2208afa9923bdc9b67
To roll this I need to update some call sites; this is because the
Serializable interface is changing.
Upstream change / review was here:
https://chromium-review.googlesource.com/c/deps/inspector_protocol/+/1879870
Change-Id: I93c4747609c6003baf1c160a68b8fb6bb07ac565
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879519
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Johannes Henkel <johannes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64618}
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.
Bug: v8:9771
Change-Id: I83382c146dd47ccb8bb329f5becb5e941e4c3968
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1871605
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64616}
Inlines UpdateEffectControlWith and AddClonedNode in GraphAssembler to address
a regression in some benchmarks caused by Add the ability for GraphAssembler
to update basic blocks.
BUG=chromium:1018661,v8:9684
Change-Id: I05513c13305465310552448192e0474f5aaa4a20
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886917
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64615}
This adds some arguments to trace events to better see whether large
times spent in these events are reasonable.
R=mstarzinger@chromium.org
Change-Id: I6097d988875d4911aff9741a1ed16590a442f60b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886912
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64614}
When inlined allocations are disabled, the space->limit() does not point to the
end of the current page. Instead, it points to the current allocation pointer so
is the same as space->top().
See how the limit is computed, if heap()->inline_allocation_disabled(), then the
limit will be the same as the requested allocation area:
```
Address SpaceWithLinearArea::ComputeLimit(Address start, Address end,
size_t min_size) {
DCHECK_GE(end - start, min_size);
if (heap()->inline_allocation_disabled()) {
// Fit the requested area exactly.
return start + min_size;
} else if (SupportsInlineAllocation() && AllocationObserversActive()) {
// ...
} else {
// The entire node can be used as the linear allocation area.
return end;
}
}
```
If we want to simulate filling up a whole page in the new space, we can instead
look at the ToSpace's page_high() which will be the end of the current page in
which we're allocating.
Bug: v8:9906
Change-Id: I81113d151bc083cd22d17ea1a4fbae7fef9dff6d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886914
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#64612}
1) don't print off-heap TypedArray elements with --mock-arraybuffer-allocator
2) print integer HeapNumbers in safe integer range with max precision:
as 9007199254740991.0 instead of 9.0072e+15
Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
Bug: v8:4153
Change-Id: Ie79fc08c44374981a840772fde4f414458d31c52
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1883565
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64609}
Remove serialized_ flags where there's only one thing to be serialized
and its pointer can be used instead.
Bug: v8:7790
Change-Id: I489bb3085cef574f81f417f950898d4348f8b9ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886911
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64608}
The {IsWasmFrame} check in {ComputeLocationFromStackTrace} only returned
true for compiled frames, but not for interpreted ones. Thus, for
interpreted frames we would run into the code for JS frames, which
assumes that a {JSFunction} is available.
This CL fixes this issue by renaming {IsWasmFrame} to
{IsWasmCompiledFrame}, and introducing a new {IsWasmFrame} method which
returns true for both compiled and interpreted frames.
R=mstarzinger@chromium.org
Bug: chromium:1018227
Change-Id: If83b4129edaad775a212ccb741f3c62eabc2addb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1883892
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64607}
ClusterFuzzer found that a context can be created by
a call to the runtime when checking for context extensions
on the bytecode graph builder.
That happens in large contexts.
Bug: chromium:1019069
Change-Id: I7ab66dceedd56476ab972d7998ef4ca6896dc868
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886691
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64605}
In some places objects where allocated on the heap and stored
in a std::unique_ptr later. This CL changes this so that a
The std::unique_ptr<T>(new T(...)) construct is replaced with
std: :unique_ptr takes ownership of new objects immediately.
std: :make_unique<T>(...) where possible.
Change-Id: Icdb4c9e7536d2b437df1a5bb6c3ad94c97e1e4cc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1871916
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64603}
Follow up from https://crrev.com/c/1874378, declare these SSSE3
instructions using a separate macro that declares the right scope.
Bug: v8:9561
Change-Id: Ia4370a4dff9e9d13b08c5e95a45670556d6ff1e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1875657
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64601}
We know statically if a context has an extension slot or not, but that
was dynamically checked.
The CL lifts the ScopeInfo chain to the compiler and does the check
statically, it only generates the undefined check if the context
has an extension slot.
Bug: v8:9744
Change-Id: I169d05bb11b36501e97af00d30ae44bedcd6be83
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876051
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64599}
This change begins making use of the fact that Torque now knows about
the relationship between classes and instance types, to replace a few
repetitive lists:
- Instance type checkers (single and range), defined in
src/objects/instance-type.h
- Verification dispatch in src/diagnostics/objects-debug.cc
- Printer dispatch in src/diagnostics/objects-printer.cc
- Postmortem object type detection in
tools/debug_helper/get-object-properties.cc
Torque is updated to generate four macro lists for the instance types,
representing all of the classes separated in two dimensions: classes
that correspond to a single instance type versus those that have a
range, and classes that are fully defined in Torque (with fields and
methods inside '{}') versus those that are only declared. The latter
distinction is useful because fully-defined classes are guaranteed to
correspond to real C++ classes, whereas only-declared classes are not.
A few other changes were required to make the lists above work:
- Renamed IsFiller to IsFreeSpaceOrFiller to better reflect what it does
and avoid conflicts with the new macro-generated IsFiller method. This
is the part I'm most worried about: I think the new name is an
improvement for clarity and consistency, but I could imagine someone
typing IsFiller out of habit and introducing a bug. If we'd prefer to
keep the name IsFiller, my other idea is to rename FreeSpace to
VariableSizeFiller and Filler to FixedSizeFiller.
- Made Tuple3 extend from Struct, not Tuple2, because IsTuple2 is
expected to check for only TUPLE2_TYPE and not include TUPLE3_TYPE.
- Normalized the dispatched behavior for BigIntBase and HeapNumber.
- Added a few new object printers.
Bug: v8:7793
Change-Id: I5462bb105f8a314baa59bd6ab6ab6215df6f313c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1860314
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64597}
Add support to verify the update schedule after ScheduledEffectControlLinearization
and ScheduledMachineLowering phases. To do so, we need to recompute the immediate
dominator tree of the scheduled blocks.
BUG=v8:9684
Change-Id: I849fb7e3e699ca56c5115d90a53006d517cf3fe5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1881160
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64596}
OrderedHashTableHandler::Delete was missed in the migration CL
crrev.com/c/1106160 because it had no callers. This CL also
migrates said function and adds usages in tests which force
instantiation (and ensure we catch these errors without MSVC).
Bug: v8:9905
Change-Id: Ieb1d1c89754f98e1d88d841d2933f46a6a4820d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1883891
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64595}
Otherwise we might reuse a node that is scheduled later in the unchanged block.
BUG=v8:9684
Change-Id: I655b538384d5ed8782d3d9bbb883037462003693
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1881155
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64594}
Since we only care about one bit in the lower 32 bits, we can always
perform smi checking while looking at the lower bits.
This improves pointer compression, since we wouldn't need to decompress,
while not affecting the non-pointer compression case.
Change-Id: Ic020fefcc92de0516148f34a3caacc60ff29556b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876050
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64593}
Otherwise the expression scope may be in a weird state and DCHECKs for valid
arrow functions in ValidateAndCreateScope willl unnecessarily fire.
Bug: chromium:1018611
Change-Id: I101b8902dce07c29aacba3e7a5e6f86d66505d5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879906
Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64591}
... and let it gracefully crash with OOM.
Bug: v8:4153, chromium:1018598
Change-Id: I20dd9874cdbdf78665de3a83d0bc1611dc088c68
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1883551
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64589}
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}
The `Printf()` macro-assembler method can be very useful as a debugging
tool. However, it's only available to the MacroAssembler making it impossible to
use in jitted code or builtins.
Change-Id: I0c1e6b98d5c6b7fc34990e87d0eb4e37f6322627
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879287
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64585}
