Declare that ByteCodeArray's source_position_table entry can also
contain Exception. (Also adds the Exception type to base.tq).
This is just a clean up for now but could be required if torque starts
generating checks for Union types (including differentiating between
different Oddballs).
Change-Id: Ie34ade100040df2f3a2e8120613b6b29d604984a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2019483
Auto-Submit: Dan Elphick <delphick@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66009}
This CL fixes a parser crash in REPL mode. Some SyntaxErrors can cause
the AST to contain NULL nodes, resulting in a crash when we want to
rewrite the AST after parsing.
Instead of re-writing a broken AST we bail early.
R=leszeks@chromium.org
Bug: chromium:1040034, chromium:1045758
Change-Id: I9c559f6de5969c8db17833ccbdb1608627b46311
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2023547
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66008}
The current implementation takes forwarding reference arguments, which
is fine when you call it with rvalues, like
make_iterator_range(V.begin(), V.end()). If you call it with lvalues
though, it doesn't do what you'd expect. ForwardIterator becomes a
reference:
Foo I = V.begin();
make_iterator_range(I, I); //ForwardIterator is deduced as Foo&
Since iterator are supposed to be small, no harm in passing them by
value.
Change-Id: I151c87304949d810c72c42f60e9d1a7151f61f83
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020780
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66007}
This adds accounting for
- StringTable that is marked black directly without going through
ProcessMarkingWorklist.
- DescriptorArray that is marked black directly inside VisitMap.
- FeedbackMetadata that erroneously was assigned kVisitDataObject
visitor id, which works only for a fixed size data object.
Bug: chromium:973627
Change-Id: If7c8bca06316f60e975bf86beea09481df8aca8b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2023545
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66006}
RequestSweep started an array buffer sweeping task even when there was
no work.
Bug: chromium:1045937
Change-Id: Ieb0835284f898dbc9b899d2b4118d9f7f6108a6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020961
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66004}
The flag naming was confusing, and inconsistent with other flags. To
disable bounds checks, you now have to say --no-wasm-bounds-checks
instead of the original --wasm-no-bounds-checks. Similarly, it is now
--no-wasm-stack-checks instead of --wasm-no-stack-checks.
R=clemensb@chromium.org
Bug: v8:10021
Change-Id: Ib57963866af794d4e47d68e520a42b4054ed2a8f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2017475
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66003}
This reverts commit 015f379aa1.
Reason for revert: Msan is unhappy: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/30702
Original change's description:
> [wasm] Cache streaming compilation result
>
> Before compiling the code section, check whether the
> bytes received so far match a cached module. If they do, delay
> compilation until we receive the full bytes, since we are likely to find
> a cache entry for them.
>
> R=clemensb@chromium.org
>
> Bug: v8:6847
> Change-Id: Ie5170d1274da3da6d52ff1b408abc7cb441bbe3c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002823
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66000}
TBR=clemensb@chromium.org,thibaudm@chromium.org
Change-Id: Idfa5b3f354816eb600ae7aab7857063d5d0d27ca
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6847
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2022949
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66001}
Before compiling the code section, check whether the
bytes received so far match a cached module. If they do, delay
compilation until we receive the full bytes, since we are likely to find
a cache entry for them.
R=clemensb@chromium.org
Bug: v8:6847
Change-Id: Ie5170d1274da3da6d52ff1b408abc7cb441bbe3c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002823
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66000}
Since the {kFinishedRecompilation} event can happen either before or
after the {kFinishedTopTierCompilation} event, we should not check it's
order relative to the other events.
R=ahaas@chromium.org
Bug: v8:10086
Change-Id: I880700b514c7c2238a0eb7791875bf0b81c64e97
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020779
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65999}
Utils::ReportApiFailure() contains logic to handle the case where no
isolate has been entered but it called Isolate::Current(), which DCHECks
when there is no active isolate. Switch to Isolate::TryGetCurrent().
See https://github.com/denoland/rusty_v8/issues/253 for background.
Change-Id: I73c28c31102c0c4ab216a925d22ad54174c7911d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020943
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65995}
We often only need to store information about declared (i.e.
non-imported) functions in a wasm module. Thus we remove the number of
imported function from a function index. We do this in several places,
with different amount of checking.
This CL extracts this logic to a new {declared_function_index} helper
and uses it wherever we do this translation. This more or less
establishes the concept of "declared function index" and hopefully
prevents errors in the future.
R=jkummerow@chromium.org
Bug: chromium:1045767
Change-Id: I7e957401495a2a8cb5d2c51031f9c69fe46195d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020763
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65994}
Fix the string representation of functions exported from asm.js modules
in the presence of imported functions.
R=jkummerow@chromium.org
Bug: chromium:1045767, chromium:667678
Change-Id: I55714252036511598eeec7fe7b81985213f7e4f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2022142
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65993}
Deserialization bypasses the heap allocators, bumping pointers into the
spaces directly, instead. So the deserializer is tightly coupled to the
implementation of the existing collector.
Here I've added an interface to heap.h for this purpose. This CL
leaves things as-is unless the TPH is enabled, in which case the new
interface is used.
Future work: use the heap.h interface in all cases.
Bug: v8:9533
Change-Id: I3b1cc81870b347fbfb509ddb4031bd3781710240
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2019482
Commit-Queue: Steve Blackburn <steveblackburn@google.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65992}
Add a test that does the same thing the devtools-frontend does when
evaluating console inputs.
1) Declare a const variable with throwOnSideEffect=true. This should
throw.
2) Declare the same const variable with throwOnSideEffect=false.
This should successfully declare the variable.
Previously it could be the case that even though we threw in 1), the
variable would fail to be initialized in 2) with a re-declaration
error.
Bug: chromium:1043151
Change-Id: I1a6126b518f7bb3788c39b9f8e3adb8850aa962a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016587
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65991}
This CL introduces the negb and negw instructions (8-bit and 16-bit
versions of neg) in the x64 assembler. These instructions are needed to
implement I32AtomicSub8U and similar WebAssembly instructions
efficiently.
The existing implementation was embedded in a generic macro, and it was
difficult to change it without introducing also the 8-bit and 16-bit
versions of many other instructions. This would have introduced a lot
of dead code. Instead this CL extracted the neg instructions from the
macro and implements them directly. This should be fine because the
assembler does not change much, and approachability of the code is
improved.
R=clemensb@chromium.org
Bug: v8:10108
Change-Id: I46099bbebd47f864311a67da3ba8ddc4fe4cd35d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2019165
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65989}
This extends the API to pass breakpoint information to Liftoff. The
Liftoff compiler identifies the places where breakpoints should be set,
but does not emit breakpoints yet.
This allows us to see the performance overhead of just checking where to
emit breakpoints (which should be negligible).
R=thibaudm@chromium.org
Bug: v8:10147
Change-Id: I3fd40ab9009e9c317a26f70b4f06db512f96a763
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2019169
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65988}
These both have to do with extremely large numbers, so it's unlikely to cause a problem in practice. Still, correctness.
First, encoding `-2147483648` in VLQ returns the value `"B"`. When decoding, we get the value `1` after reading the base64. We then check if the first bit is set (it is) to see if we should negate it, then we shift all bits right once. Now, `value` will be `0` and `negate` will be `true`. So, we'd return `-0`. Which is a bug! `-0` isn't `-2147483648`, and we've broken a round trip.
Second, encoding any number with the 31st bit set, we'd return the opposite sign. Let's use `1073741824`. Encoding, we get `"ggggggC"`. When decoding, we get the value `-2147483648` after reading the base64. Notice, it's already negative (the 32nd bit is set, because the 31st was set and we shifted everything left once). We'd then check the first bit (it's not) and shift right. But we used `>>`, which does not shift the sign bit. We actually wanted `>>>`, which will. Because of that bug, we get back `-1073741824` instead of the positive `1073741824`. It's even worse if the 32nd and 31st bits are set, `-1610612736` becomes `536870912` after a round trip.
I recently fixed the same two bugs in Closure Compiler: https://github.com/google/closure-compiler/commit/584418eb
Change-Id: Ib6592ad50ae3764479c1a766bbb19042ee83b99d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2018882
Auto-Submit: Justin Ridgewell <jridgewell@google.com>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65987}
When printing the source string, a backslash-newline sequence ('\\\n',
'\\\r', '\\\u2028', '\\\u2029') should be formatted as '\n', '\r',
'\u2028', '\u2029', respectively. Prior to this CL it was formatted as
a backslash followed by the literal newline character.
Bug: v8:8615
Change-Id: Iac90195c56ea1707ea8469066b0cc967ea87fc73
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016583
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65986}
When ArrayBufferExtensions are enabled, sweep the extensions outside of
the GC pause concurrently to the application. The following GC will make
sure that the previous concurrent sweep operation is finished.
This CL introduces Heap::array_buffer_sweeper() that is both
responsible for tracking all extensions but also for sweeping.
Bug: v8:10064
Change-Id: I113cd625445a7d59ffb7a9de8b25a15a72b02b99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2010107
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65984}
Remove the execution tier check for simd tests. On archs without
Liftoff, those tests that are configured to run on Liftoff will fail
with this check, since they bail out to TF.
We remove this check for now, but will think of a way to enforce this in
a more platform specific way.
Bug: v8:9909
Change-Id: Id56f841fe6e342434af3dbcdaef0a8a284614994
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2019924
Reviewed-by: Milad Farazmand <miladfar@ca.ibm.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65983}
Otherwise the side effect is already applied before we throw the exception,
already breaking the environment.
Bug: chromium:1043151
Change-Id: I6d6b4706481bd8eaead6de3503aabc4bad9fb6de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016597
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65982}
SafeStackFrameIterator::Advance() will stop at wasm_to_js frames, so we
should fully expect that they show up when calling frame() after
Advance().
This fixes some breakages for profiling wasm and asm.js.
Bug: chromium:1010534, v8:10150
Change-Id: Ifc78cd9eba33e777b33fc1cbea19ee376b25299c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2019485
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65980}
This CL attempts to remove the #undef check
from the Presubmit for .cc files because we
are removing Jumbo support.
Bug: chromium:994387
Change-Id: I1bb6d22393c1b533f23dd586e5028ecc6d254c99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2013119
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Wez <wez@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Almothana Athamneh <almuthanna@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65978}
Port b110d4808b
Original Commit Message:
This relands commit 009993adb4.
The fix is in liftoff-assembler-ia32.h, the codegen was incorrect.
Original change's description:
> Implement f32x4.splat and enable handling this in Liftoff.
>
> We add a new macro for defining test cases to run on TurboFan, Liftoff,
> interpreter, and scalar lowering.
>
> Also add an assertion that the execution tier used is what we expected
> it to be. This is useful for Liftoff, because by default it falls back
> to TurboFan when it encounters an unimplemented opcode.
>
> Bug: v8:9909
R=zhin@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: I0fc54cd04379a6c65aa2bee64bf4cf9dad5b9636
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2019582
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#65977}
As these are simple methods, and for consistency with the GraphAssembler
interface, the getters should not be capitalized.
R=ecmziegler@chromium.org
Bug: v8:10123
Change-Id: I51871115b061bca4483dc23e982303508d9d8f55
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2017471
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65976}
This changes the WasmGraphBuilder to use the GraphAssembler for storing
the current effect and control, instead of having separate fields.
This will allow us to use GraphAssembler methods anywhere in the
WasmGraphBuilder without first transferring the WasmGraphBuilder's
effect and control to the GraphAssembler and storing it back afterwards.
Some methods (StackCheck, BuildCallToRuntimeWithContext) have been
changed to work on the current effect and control instead of receiving
them as parameters. This is necessary to also use the GraphAssembler
there, and it makes the code a bit easier.
R=ecmziegler@chromium.org
Bug: v8:10123
Change-Id: Ia9f6359cfe44a67a875c3eb0fe51f87db8bd17db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2017470
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65975}
TailCalls have no output effect, similarly to e.g. return nodes. Thus,
don't put them in the effect chain.
The current graph verifier does not complain about this, but once we
switch to the GraphAssembler, we will hit a SLOW_DCHECK there because
we are trying to use a node as effect which has no effect output.
R=jkummerow@chromium.org
Bug: v8:10070
Change-Id: I23d9516eb9bd42a5aca46b09ca74830eafce635c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2017474
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65973}
We currently print asm.js functions converted to wasm as
"function foo() { [native code] }", even though without asm to wasm
translation we get the proper source code. This is an observable
difference that should not be, and also foozzie finds this frequently in
different variations.
This CL makes us remember the start position (position of the "function"
token) and end position (right behind the closing "}") of each function
we transform to wasm. These offsets, together with the Script that
contained the function, allows us to reconstruct the source code of the
function for the {toString()} method.
R=jkummerow@chromium.org
Bug: chromium:667678
Change-Id: If22471cad4cefdfc67f6d1b8fda85aa0eeb411bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016582
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65972}
The code did originally only handle the int32 case, but was then
extended to all wasm types in https://crrev.com/c/1965577. The comments
and variable names still mention the int32 type only though.
This CL fixes that.
R=ecmziegler@chromium.org
Bug: v8:10070
Change-Id: I3b1fa4047ee7ee9f283dce3758f6b8a39c964b22
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2017723
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65970}
This code is commented out since a long time (at least since 2008), but
I found it to be useful information.
Instead of printing the full script information, just print the {Brief}
version. In a debugger, users can still print the full information based
on the printed pointer value if needed.
R=jkummerow@chromium.org
Change-Id: I79b19f0bbc8797746b916c1f5860f727c0f0ac39
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2015240
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65969}
This cleans up string-util.h a little. Instead of distinguishing
BinaryStringBuffer from StringBufferImpl (which has a legacy
::adopt() interface), provide two functions for making StringBuffer
from either an 8 bit (std::vector<uint8_t>) or a 16 bit (String16)
source, and keep the classes in the .cc file only. Since it's easy
enough, this adds a class also for the empty string buffer as there's
no need to keep an empty vector / String16 this way.
No public API changes here.
Change-Id: Idb25fe24ea94f27f8001d552cede089e04eacd32
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016015
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Johannes Henkel <johannes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65964}
This relands commit 009993adb4.
The fix is in liftoff-assembler-ia32.h, the codegen was incorrect.
Original change's description:
> Implement f32x4.splat and enable handling this in Liftoff.
>
> We add a new macro for defining test cases to run on TurboFan, Liftoff,
> interpreter, and scalar lowering.
>
> Also add an assertion that the execution tier used is what we expected
> it to be. This is useful for Liftoff, because by default it falls back
> to TurboFan when it encounters an unimplemented opcode.
>
> Bug: v8:9909
Bug: v8:9909
Change-Id: I7daacbe8b195d9212367190c515b0babbc457a88
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2018043
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65963}
