It is moved to a recipe module as a resource in https://crrev.com/i/678188.
R=machenbach@chromium.org
Bug: chromium:880732
Change-Id: If64b349d92d5da8452b32474d9d0c22d18155bc8
Reviewed-on: https://chromium-review.googlesource.com/1222126
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Sergiy Byelozyorov <sergiyb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55995}
This removes the last unconditional read accesses to the heap, but
required a significant refactoring.
- Remove HeapObjectRef::type().
- Change HeapObjectData::Is* testers to look at the instance type
in HeapObjectData::map().
- Remove ObjectRef::oddball_type()
- Add MapRef::oddball_type()
- Add MapRef::is_undetectable().
- Add MapRef::is_callable().
- Remove JSHeapBroker::HeapObjectTypeFromMap()
- Remove Type::For(JSHeapBroker*, Handle<Map>)
- Add BitsetType::Lub(MapRef).
- Add Type::For(MapRef).
- Add Type::For(HeapObjectType).
- Add HeapObjectRef::GetHeapObjectType(). THIS IS TEMPORARY.
As the last item suggests, I couldn't actually remove the
HeapObjectType class yet. See the explanation in the code.
Bug: v8:7790
Change-Id: I508e4bd5337277b0050f2204392fc36f41032fe9
Reviewed-on: https://chromium-review.googlesource.com/1228033
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55994}
In the near future all ia32 ASM builtins must be audited & possibly refactored
to ensure they do not address ebx (= kRootRegister).
This CL adds mechanisms to verify ebx usage. SupportsRootRegisterScope marks
regions that are root-register-ready (i.e. does not use ebx).
AllowExplicitEbxAccessScope marks regions that are explicitly allowed to use
ebx, e.g. because they spill and restore its value at all boundaries and do not
contain any root-relative accesses.
Consistency is verified by calling the new AssertIsAddressable function at
strategic spots in the Assembler.
All of this code is temporary and should be removed once ia32 fully supports
the kRootRegister.
Bug: v8:6666
Change-Id: I7c5514794db0da889bdae9e3c23bc0d54780879d
Reviewed-on: https://chromium-review.googlesource.com/1226805
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55992}
If type checks in simplified lowering produced dead value (i.e., of
type Type::None()), we have only propagated deadness along value
edges. With this CL, we also insert an Unreachable node after every
effectful node that produces dead value.
This is more consistent with dead code elimination, which also inserts
unreachable nodes after effectful nodes with value output None.
Bug: chromium:884052
Change-Id: Idcb168461f05f1811b2c9c16ab8ff179b259fbd3
Reviewed-on: https://chromium-review.googlesource.com/1228125
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55987}
Word8 and Word16 representation is treated like Word32 for the sake of
TurboFan's representation selection, but this was missing from the
Word64 conversions.
Bug: chromium:884933, v8:4153, v8:7881, v8:8171, v8:8178
Change-Id: If7b69cdd02b12546d87bba0643e9ee9cb35cb299
Reviewed-on: https://chromium-review.googlesource.com/1229953
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55983}
I'm also changing the function signature to take the descriptor_index
instead of the FieldIndex, because this lets me reuse the vector of
property descriptors as storage.
Bug: v8:7790
Change-Id: Ie9dadcba2204b6825e5791f9c630fc8b1079a930
Reviewed-on: https://chromium-review.googlesource.com/1227873
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55981}
Port 0c296cb229
Original Commit Message:
This change introduces the necessary conversion operators to convert
from Word64 to other representations (Tagged, Word32, Float64, etc.),
and plugs in the Word64 representation for NumberAdd/NumberSubtract,
such that TurboFan will go to Int64Add/Sub on 64-bit architectures
when the inputs and the output of the operation is in safe integer
range. This includes the necessary changes to the Deoptimizer to be
able to rematerialize Int64 values as Smi/HeapNumber when going back
to Ignition later.
This change might affect performance, although measurements indicate
that there should be no noticable performance impact.
The goal is to have TurboFan support Word64 representation to a degree
that changing the TypedArray length to an uint64_t (for 64-bit archs)
becomes viable and doesn't have any negative performance implications.
Independent of that we might get performance improvements in other areas
such as for crypto code later.
R=bmeurer@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: I2119f156c4ddf942ea09ff8ed52e1c6cb32477f2
Reviewed-on: https://chromium-review.googlesource.com/1228634
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#55971}
Port 6346cdb649
Original Commit Message:
This adds support to TurboFan's representation selection for the Word64
representation, and makes use of that to handle indices for memory access
and allocation instructions (i.e. LoadElement, StoreElement, Allocate,
etc.). These instructions had previously used Word32 as representation
for the indices / sizes, and then internally converted it to the correct
representation (aka Word64 on 64-bit architectures) later on, but that
was kind of brittle, and sometimes led to weird generated code.
The change thus only adds support to convert integer values in the safe
integer range from all kinds of representations to Word64 (on 64-bit
architectures). We don't yet handle the opposite direction and none of
the representation selection heuristics for the numeric operations were
changed so far. This will be done in follow-up CLs.
This CL itself is supposed to be neutral wrt. functionality, and only
serves as a starting point, and a cleanup for the (weird) implicit
Word64 index/size handling.
R=bmeurer@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: Ic7ea30639dea3c5f8a59e7100a15d5ed50073c20
Reviewed-on: https://chromium-review.googlesource.com/1228416
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#55970}
Temporarily disable one-shot optimization for
debug-evaluate-no-side-effect-builtins-2 to fix the gc stress test.
This issue will be fixed in the future CL
(https://chromium-review.googlesource.com/c/v8/v8/+/1196725)
that adds new bytecodes for loads and stores and one-shot optimizations
will be enabled again.
Change-Id: I6475557778da4553b5b6cbba1fda14c52d3dd91b
Reviewed-on: https://chromium-review.googlesource.com/1228063
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Chandan Reddy <chandanreddy@google.com>
Cr-Commit-Position: refs/heads/master@{#55969}
On Intel platforms, the kX64Cmp32 and kX64Test32 operations in
TurboFan's backend automatically truncate their inputs to Word32
(aka they don't look at the upper bits), so the instruction selection
can silently ignore TruncateInt64ToInt32 on the inputs.
Bug: v8:8178
Change-Id: Ia50a38cac927e5b2155f092a8885da255a3dddca
Reviewed-on: https://chromium-review.googlesource.com/1227935
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55968}
Instead include it in the files that need to use it.
Change-Id: I2321f423ddcc1c0e779332c2e7d1a372bfb4ebbb
Reviewed-on: https://chromium-review.googlesource.com/1227305
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55964}
This avoids unnecessary stack-walks to determine the current context in
WebAssembly runtime functions, in cases where the calling stub already
determined the calling instance and can just set the context register
itself before calling into the runtime.
R=clemensh@chromium.org
Change-Id: Iba02d479a7dad8907195bf94efb9d559be20a6d1
Reviewed-on: https://chromium-review.googlesource.com/1228035
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55962}
js-to-wasm wrappers check whether trap handlers are enabled
process-wide, but are independent of their actual usage in the current
instance. Thus remove this unneeded parameter.
R=mstarzinger@chromium.org
Bug: chromium:862123
Change-Id: I3793213864568b4e26eb3414239033491e4539f5
Reviewed-on: https://chromium-review.googlesource.com/1226974
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55961}
This is a reland of a4105a437d
Original change's description:
> [wasm] Implement handling of exported/imported exceptions.
>
> This implements the proper semantics for matching exported/imported
> exceptions by using the notion of an "exception tag" that is global to
> the system. It can be used to match exceptions in one module against
> exceptions declared and/or thrown in another module (or instance).
>
> R=clemensh@chromium.org
> TEST=mjsunit/wasm/exceptions-shared
> BUG=v8:8091
>
> Change-Id: I37586d7be5d5e6169b3418dfbc415b26dd4750dd
> Reviewed-on: https://chromium-review.googlesource.com/1226976
> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#55940}
Bug: v8:8091
Change-Id: Ib85f099b26a8323a8a00299b5aaeb05aaff3c3c6
Reviewed-on: https://chromium-review.googlesource.com/1227975
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55959}
Cleanup the JSArrayBuffer bit fields to use the proper object macros
that are now otherwise used consistently across the code base. Also
change TurboFan to consistently bailout when it sees an array buffer
that was previously neutered, so that the generic path / builtins are
again the chokepoints for the spec violations (the fact that we don't
always raise exceptions when we see a neutered array buffer), except
for the ArrayBufferView accessor inlining in the JSCallReducer, where
we still turn the values into zero (because we don't have access to
a CALL_IC speculation guard in the common case).
This also removes the ArrayBufferWasNeutered simplified operator, and
does regular LoadField + Number bitwise operations instead, which is
good enough and allows us to get rid of a lot of unnecessary complexity.
Bug: v8:4153, v8:7881, v8:8015, v8:8171, v8:8178
Change-Id: I4ce79ece762c632e6318f2ab7bcc6b2f82383947
Reviewed-on: https://chromium-review.googlesource.com/1226887
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55958}
We still see occasions of "WebAssembly Instantiation: Out of memory:
wasm memory", e.g. on the N5X arm64 bot.
We already have a retry-loop around the {ReserveAddressSpace} call, so
this error can only happen if {AllocatePages} fails.
I cannot easily reproduce, so I will land this CL and hope that it
fixes the flake.
We might eventually replace all these gc-then-retry loops by a better
mechanism which knows about process-wide allocations. Currently,
{AllocatePages} is isolate-independent, and only calls
{Platform::OnCriticalMemoryPressure}, but this call does nothing on the
default platform. So trigger a GC on the current isolate instead.
R=mlippautz@chromium.org
Bug: chromium:883639, v8:7872, v8:8158
Change-Id: Ib4e4a4a5f6b598d5832c327b1fc83ccb3bada9bc
Reviewed-on: https://chromium-review.googlesource.com/1226886
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55955}
Only read-only pages don't have properly initialized reservation object.
This is a reland of b0edf8e66a
Bug: v8:8096
Change-Id: Ib2745d18e93788b92b0f9ffcaf996a1dad886b04
Reviewed-on: https://chromium-review.googlesource.com/1226875
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55953}
... in order to avoid page allocator filtering when notifying leak sanitizer.
This is a reland of 0606bf91ed
Bug: v8:8015
Change-Id: I314eee7699ce2c8abeeafce4fcf185810ac252a9
Reviewed-on: https://chromium-review.googlesource.com/1226918
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55952}
We do not have to collect feedback for function calls in one-shot code.
This CL avoids allocating CallICslots for each function call by
emitting CallNoFeedback bytecodes. We save one CallICSlot (two entries
in feedback vector) per function call in One-shot.
Bug: v8:8072
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ic2580e5972acd5124c2e71d540985736ce797fe8
Reviewed-on: https://chromium-review.googlesource.com/1178051
Commit-Queue: Chandan Reddy <chandanreddy@google.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55951}
The computation to find the hash entry is already performed on Word64,
and the actual value access later is also performed on Word64 indices,
so there's no point to go to Word32 in between.
Bug: v8:8015, v8:8178
Change-Id: I160e02166beceb79dcc8e69f9c365871a4c42606
Reviewed-on: https://chromium-review.googlesource.com/1226648
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55950}
Abort incremental marking pulls in the requirement to also be able to abort on
the embedder side. In practice, aborting is never really needed and the GC
should just finalize the existing collection and do an atomic followup if exact
marking information is required.
Bug: chromium:843903
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Ic471332d01b0c4be26b71a06248af03255c61a9d
Reviewed-on: https://chromium-review.googlesource.com/1225705
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55949}
VirtualMemory objects can be moved since https://crrev.com/c/1213062,
so there is no need any more to return them via pointer argument. This
also makes the {AllocVirtualMemory} and {AlignedAllocVirtualMemory}
functions superfluous.
R=ishell@chromium.org, titzer@chromium.org
Bug: v8:8015
Change-Id: Id72921e1c66a6c10be6647194603b8283e010e24
Reviewed-on: https://chromium-review.googlesource.com/1226972
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55947}
