Properly handle termination exceptions in TLA modules.
Bug: v8:9978
Change-Id: Ica70a55d1f54ec89d175d7c846e9a405eaffe0a0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1920750
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65135}
Refbuilds still require natives blob. We need to keep the logic for
handling it on android until the next branch point.
No-Try: true
Bug: chromium:1026556
Change-Id: I8375400e0d3ea0f881ef56edc7de8574ae94f3e0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928862
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65134}
With https://crrev.com/c/1925524 we are moving elements on the stack by
their offset, but this transfer recipe is still checking the indices of
src and dst, which is incorrect.
Bug: chromium:1027410
Change-Id: Id7c7523c097bd06f3d107cb4d9de1052fc082105
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1930606
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65129}
FunctionBlueprint holds a SharedFunctionInfo, FeedbackVector and a
Hints object that represents what we know about the Context of
the "function-to-be." Since we occasionally synthesize a
FunctionBlueprint object from a JSFunction (when we have it),
it can happen that sometimes the Context hint is a concrete
Context object, and other times it's a VirtualContext, representing
a context created sometime during the bytecode execution of the
function under optimization. Moreover, both such FunctionBlueprints
can exist in the same run due to the vagaries of CALL_IC feedback
(ie, sometimes you have a JSFunction, other times you don't).
More details in doc:
https://docs.google.com/document/d/1F1FxoDzlaYP5l5T6ZcZacV3LCUp5elcez05KWj-Mp78/edit?usp=sharing
Bug: crbug:1024282
Change-Id: Id4055531333b3dcbdb93afd23d9a226728292e11
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1926151
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65127}
port aafbc13https://crrev.com/c/1900662
Original Commit Message:
[wasm-simd] Implement i64x2 shifts for arm
Change-Id: I036610bdcf8e36879cf7a47fbf6e28034345a945
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928499
Auto-Submit: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65126}
RuntimeCallTimerScope can now be called with the optional flag
kThreadSpecific, which chooses the appropriate RuntimeCounterId given
whether the RuntimeCallStats object is for the main isolate thread or a
worker thread.
While this doesn't change any existing timers over to use this flag it
does add checks that in the default case that any thread-specific
counters are the correct one given the thread status.
Bug: v8:10006
Change-Id: Idb545714284bcd2e2fdca991918ddf976dcbdf70
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928863
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65125}
port ea06b01https://crrev.com/c/1925613
Original Commit Message:
[wasm-simd] Implement i64x2 add sub for arm
Also some cleanup reordering of instruction codes.
Change-Id: I151668f4125c46b35b08ddd3640341125f6fdbdf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928500
Auto-Submit: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65124}
The previous implementation incorrectly used instructions for 32-bit
data, this CL fixes it to implement 64-bit operations.
Change-Id: Ib8e5236ea35f3a2c0e37e647ea89aad6a1127425
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928501
Auto-Submit: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65123}
This scenario is where user is at the end of Wasm execution and do
some stepping. Hence, user should be back at Javascript frame. We
can detect that stepping as it exits Wasm Interpreter and prepare
debugging as a step-out-ish in Javascript.
Bug: chromium:823923, chromium:1019606, chromium:1025151
Change-Id: I29022af0d5e5dcf78d87e83193f6e16fec954e87
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1912985
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65122}
Currently these events are emitted by Blink in GC prologue/epilogue.
That however does not respect event nesting and breaks with future
perfetto changes. This CL emits the events inside V8 using a scope to
guarantee proper event nesting. The events are same except for the
"type" argument that now gets more detailed information.
The corresponding Blink CL that removes these trace events:
https://chromium-review.googlesource.com/c/chromium/src/+/1929227
Bug: chromium:1026658
Change-Id: Ifbfab647f40f81af7acf315ff4608b9dc9444f94
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928857
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65120}
We possibly need to load the global object from the global proxy as the holder
of the named interceptor.
Change-Id: I0f9f2e448630608ae853588f6751b55574a9efd9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1930903
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65119}
This is a first step towards allowing expressions for array sizes.
So far, local variable bindings used a VisitResult and a const flag.
This doesn't allow for local bindings to alias other things, like
heap references. While this is not generally a feature we need,
it will be helpful to create bindings when evaluating array sizes,
since we want to grant access to the preceding already initialized
object fields, but not to the whole object, which is not completely
initialized yet.
LocationReference already captures the notion of any readable and
assignable location, so it is a good fit to be used for local bindings.
The const attribute is no longer needed, since LocationReference already
has a notion of constness for stack ranges (that is,
LocationReference::Temporary vs LocationReference::VariableAccess).
Bug: v8:10004 v8:7793
Change-Id: Ibe0a43e898e5c2c10d6739e2496d92dda542e6cc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928852
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65117}
This CL adds build flags for pluging in third-party heap implementation.
Additionally it redirects allocation requests when the flags are on.
Bug: v8:9533
Change-Id: I7ef300ca9dc2b5f498a13211611ae4b4b3df8fa0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928860
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65114}
A previous CL (https://crrev.com/c/1926769) changed hashing to always
treat the input as signed values. This causes problems, since the hash
of a one-byte string differs the hash of the identical two-byte string.
Hence this CL switches to treating all values as unsigned in hashing.
The bug cannot easily be reproduced in v8 alone, since we would need to
create an internalized two-byte string, which contains one-byte data.
Blink manages to create such a string via external strings.
R=jkummerow@chromium.org
Bug: chromium:1025184, chromium:1027131
Change-Id: Id41aa0e463691c02099a08c6e9d837a079c872df
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1930615
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65113}
If v8_enable_object_print is set to true, we should use Object::Print
instead of Brief(Object).
R=jkummerow@chromium.org
Change-Id: I70583c15834f9332aba7760b5e104136712d4e0d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1930613
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65112}
This patch changes many callers of GetStackOffsetFromIndex to directly
use the offset that is stored in the VarState (and other structures).
The tricky part here is that in all archs, GetStackSlotOffset no longer
relies on kFirstStackSlotOffset, because the offset stored in VarState
is relative to the constant space (instance offset), and not offset of
the first stack slot.
For example, for slot 0, the offset was also 0, because it was relative
to the first stack slot offset (which in x64 is fp-24). With this
change, the offset of slot 0 is now 8, but since GetStackSlotOffset is
relative to fp-16, it ends up being fp-24 still.
Because of this change, callers of GetStackOffsetFromIndex need to add
1 to whatever index they were passing. Instead of doing that, we change
GetStackOffsetFromIndex to add 1 inside the body.
After this change, the only callers of GetStackOffsetFromIndex will be
inside of FillStackSlotsWithZero, because they still rely on index to
keep track of how many params were processed, and also how many locals
there are in order to zero those slots, and these is relied on by
RecordUsedSpillSlot to allocate sufficient stack space.
Bug: v8:9909
Change-Id: I52aa4572950565a39e9395192706a9934ac296d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925524
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65109}
This introduces a new keyword "shape" in addition to "class",
which allows the definition of a type that extends a JSObject
subclass and specifies one or several maps with statically
known in-object properties.
Differences compared to normal classes:
- Shapes are transient since they specify maps instead of
instance types.
- Shapes have a known size.
- Fields of shapes are always in-object properties. In particular,
this means that their offset is after kHeaderSize.
- It's forbidden to inherited from shapes.
- Since shapes usually specify NativeContext-dependent maps, it's
not possible to write runtime type-checks for them. Thus this CL
avoids mapping them to their own TNode type, as the CAST macro
won't work properly. We had runtime-checks for some of them
nevertheless, some of them scarily confusing like
IsJSSloppyArgumentsObject, that actually just checked the instance
type.
Drive-by cleanups and simplifications:
- Allow subclassing from non-abstract classes and remove
@dirtyInstantiatedAbstractClass. This attribute stems from a mis-
conception of how instance types work, and with this change it
ceases to have semantic influence.
- Replace the existing JSArgumentsObject subclasses into two shapes.
JSArgumentsObjectWithLength had to be removed since shapes don't
support subclassing.
- Place kHeaderSize correctly for objects with indexed fields.
Design doc:
https://docs.google.com/document/d/1zPy2ZYfNFjeEuw6Mz3YJA-GaPGbdcSYam3SrS7ETzRU
Bug: v8:8944
Change-Id: Iabf185ccd27d0900e0890539a7fe9eaa8bf2d50e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1917140
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65108}
This is a reland of 2072772592
The fix is in liftoff-assembler-arm64.h in FillStackSlotsWithZero,
in the else case for bigger counts to fill, the argument passed to Sub
was incorrect. We were passing offset relative to first slot, but it
should be offset relative to instance, so there is an off by 1 slot error
when zeroing, and ended up zeroing the stack slot holding instance.
Original change's description:
> [liftoff] Use stack slot offsets instead of indices
>
> Spill/fill now take offsets instead of indices. We provide a
> helper, GetStackOffsetFromIndex, for callers. This is currently only
> useful while slot sizes are still fixed to 8 bytes.
>
> StackTransferRecipe's RegisterLoad now works in terms of offset.
>
> LiftoffStackSlots work in terms of offset as well.
>
> TransferStackSlot currently still works in terms of indicies, but can be
> converted to use offsets in a subsequent change.
>
> Bug: v8:9909
> Change-Id: If54fb844309bdfd641720d063135dd59551813e0
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1922489
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65049}
Bug: v8:9909
Change-Id: I311da9d3bb1db8faf8693079177c77a7b3754243
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925131
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65107}
port a7b9e58https://crrev.com/c/1900661
Original Commit Message:
[wasm-simd] Implement i64x2 neg for arm
Change-Id: Ia4f52b26e4c3d6e2833b01246bd917d5e62ca79d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924003
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Auto-Submit: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Cr-Commit-Position: refs/heads/master@{#65103}
Remove sep(Left|Right)Snap as they were never read from
Bug: v8:7327
Change-Id: Id09fa0ec606a75d40cc946b354bc1a260f3b68ac
Notry: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928855
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65100}
InstanceBuilder::LoadTableSegments - Throw RuntimeError instead of
LinkError
WasmGraphBuilder::TableInit & WasmGraphBuilder::MemoryInit - Do not
check for active/dropped status if size == 0
WasmGraphBuilder::MemoryFill - Throw out-of-bounds error BEFORE
attempting any memory operations if necessary
R=ahaas@chromium.org
Bug: v8:9865
Change-Id: I6a67779dc99fdc1c6bda6a2526d0e9ee5385f3ed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924442
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65098}
It was just an add used only in one place, so I inlined it.
I also noticed that some methods were using scratch registers as
parameters but didn't really need to do so.
Bug: v8:7703
Change-Id: Ia1e5570d478673cb0835cff97e3a37d9a35c60a6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924266
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65097}
This is a reland of f2a74165bf
Original change's description:
> [regexp] Re-execute regexp when '.indices' is accessed.
>
> Instead of storing a pointer to the last_match_info, which may
> change, this cl modifies JSRegExpResult to store a pointer to
> the original JSRegExp which generated it, as well as additional
> data needed to re-execute the match.
>
> Basically a straight copy and tidy off jgruber@'s prototype:
> https://chromium-review.googlesource.com/c/v8/v8/+/1876810
>
> Bug: v8:9548
> Change-Id: I11b7deae681b8287e41e8d0e342291ff484751fb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1910129
> Commit-Queue: Joshua Litt <joshualitt@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65053}
Bug: v8:9548
Change-Id: Ieeba4b1ae59ef0c7946d654dc314adfae09d24b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925554
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65096}
An initial investigation of using GraphAssembler in JSCallReducer.
This CL ports two simple reductions (ReduceMathUnary,
ReduceMathBinary) as well as a slightly more involved reduction with
branching control flow (ReduceStringPrototypeSubstring). The graph
assembler abstracts away the details of maintaining effect and control
edges. Resulting code ends up looking very similar to CSA.
Newly introduced:
- Typing through TNode.
- IfBuilder1 for nicer if-then-else sequences that return exactly 1
value. Future CLs will add more convenience builders that follow this
pattern.
- Many small readability improvements through helper functions.
Bug: v8:9972
Change-Id: Iaa186b76c006e07c8d69a74f340a4912577a32a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1914204
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65095}
It could also be a DeadValue.
A regression test will take a while but the fix is straightforward.
Bug: chromium:1027045
Change-Id: I49a66668b7189b7ea7d6d79d514b9e0de3edc966
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928853
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65094}
This is an unmodified reland of 3c98a2a36a.
The actual issue was fixed in https://crrev.com/c/1926769.
Original change's description:
> [wasm] Prevent breakpoints on nonbreakable positions
>
> If a breakpoint is set on a non-breakable position, the wasm interpreter
> just stores the value 0xFF (kInternalBreakpoint) in the function body
> (actually, a copy of the function body). This might overwrite immediates
> and cause subsequent failures in the wasm interpreter.
>
> In JavaScript, breakpoints are just forwarded to the next breakable
> position. This CL implements the same for WebAssembly.
> A cctest tests this behavior, and the existing
> wasm-stepping-byte-offsets.js inspector test is extended to also set the
> breakpoint within an i32 constant immediate.
>
> R=leese@chromium.org, mstarzinger@chromium.org
> CC=bmeurer@chromium.org
>
> Bug: chromium:1025184
> Change-Id: Ia2706f8f1c3d686cbbe8e1e7339d9ee86247bb4a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925152
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65070}
Bug: chromium:1025184
Change-Id: I5e16df645bbacf039b7a5e55a0c2a64cdb4c6a32
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1926152
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65093}
Follow-up to c968607e12 to make
LayoutTests happy.
Tbr: verwaest@chromium.org
Change-Id: I02758faa8ed1f06f1faf615047a40ec115887a4a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928856
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65092}
&vector[i] is invalid unless 0 <= i < vector.size(). This means:
- &vector[0] is invalid if the vector is empty.
- &vector[vector.size()] is not a valid way to point past the end of the
vector.
Fix these to use vector.data() + vector.size() which is the defined to
get begin and end pointers for a vector.
Bug: chromium:1027059
Change-Id: Ife1f0e64807b32ebdca66dba8ffc206d90a0de75
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1929071
Auto-Submit: David Benjamin <davidben@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65091}
Hashing should ignore the signedness of the type, since different
platforms might define standard types like {char} as either signed or
unsigned. This leads to problems if hashes are included in test
expectations, see https://crrev.com/c/1926032 and
https://crbug.com/1025184#c26.
This CL avoid such problems by always treating the input as signed
values. This also reduces binary size, since the instantiations for
int8_t and uint8_t are identical now and are folded together by the
compiler / linker.
R=jkummerow@chromium.org
Bug: chromium:1025184
Change-Id: I3fee4d8662dd1c31cd6483639fe4edd4511662c5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1926769
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65090}
Also some cleanup reordering of instruction codes.
Bug: v8:9813
Change-Id: I35caad0b84dd5824090046cba964454eac45d5d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925613
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65088}
