The revert somehow lost the contents of regress-2825.js.
NOTRY=true
NOPRESUBMIT=true
NOTREECHECKS=true
BUG=chromium:662928
Review URL: https://codereview.chromium.org/2483863002 .
Cr-Commit-Position: refs/heads/master@{#40806}
This moves all tests currently working with the inspector debugger wrapper to
test/debugger.
BUG=v8:5530
Review-Url: https://codereview.chromium.org/2480223002
Cr-Commit-Position: refs/heads/master@{#40804}
This
- removes the ParserRecorder base class,
- devirtualizes the LogFunction and LogMessage functions,
- reuses the SingletonLogger for all preparser calls
In a subsequent step the preparser should probably log directly to the CompleteParserRecorder rather than indirectly through the singleton logger...
BUG=
Review-Url: https://codereview.chromium.org/2474393003
Cr-Commit-Position: refs/heads/master@{#40803}
The spec defines that indirect calls in WebAssembly code should cause a
validation error if no function table exists.
The CL contains the following changes:
1) Throw a validation error for indirect calls if the function table
not exist.
2) Do not create TF nodes to throw a runtime error for indirect calls
if the function table does not exist.
3) Fix existing unit tests by creating a dummy function table.
4) Add new a new test which tests that indirect calls without function
table cause a validation error.
R=rossberg@chromium.orgCC=titzer@chromium.org
TEST=unittests/AstDecoderTest.IndirectCallsWithoutTableCrash
Review-Url: https://codereview.chromium.org/2484623002
Cr-Commit-Position: refs/heads/master@{#40802}
The maximum memory size is a user-defined upper limit for the size of
the memory of a WebAssembly instance. The actual limit is the minimum of
the user-defined limit and the V8 limit. With this CL we allow the
user-defined limit to be greater than the V8 limit, which is required by
the spec.
R=titzer@chromium.orgCC=gdeepti@chromium.org
TEST=unittests/WasmModuleVerifyTest.MaxMaximumMemorySize
Review-Url: https://codereview.chromium.org/2484643002
Cr-Commit-Position: refs/heads/master@{#40801}
This CL adds further support to the test wrapper. We are now able to
run almost all mjsunit/debug-step-* tests using the inspector backend.
debug-stepframe-* tests are not yet supported since inspector does not
know a 'frame' step type.
The interface has also been improved to be able to move these tests to
inspector mostly without modification.
BUG=v8:5330
Review-Url: https://codereview.chromium.org/2466273005
Cr-Commit-Position: refs/heads/master@{#40800}
When we hit an unspported field store, only flush the state of
potentially aliasing objects, but don't flush the full state table.
R=jarin@chromium.org
BUG=v8:5608
Review-Url: https://codereview.chromium.org/2476213002
Cr-Commit-Position: refs/heads/master@{#40799}
LiveObjectIterator sometimes runs concurrently to the main thread. In this
scenarios we are not allowed to access memory of live objects in non-atomic
ways. Use synchronized reads where needed.
Correctness (already ok in current state):
- Reading a larger size is fine per definition.
- Reading a smaller size is fine since are guaranteed that one word fillers will
follow.
BUG=v8:5583
R=ulan@chromium.org,hpayer@chromium.org
Review-Url: https://codereview.chromium.org/2477823003
Cr-Commit-Position: refs/heads/master@{#40798}
Drive-by-fix 1: be more precise in machine representations for
AllocateNameDictionary to make --turbo_verify_machine_graph happy.
Drive-by-fix 2: Improve graph verifier output by printing input
representation.
BUG=
Review-Url: https://codereview.chromium.org/2475913002
Cr-Commit-Position: refs/heads/master@{#40797}
The test case did not test anything in its original form. Fix it and add
documentation.
BUG=v8:5339
Review-Url: https://codereview.chromium.org/2481733002
Cr-Commit-Position: refs/heads/master@{#40794}
We need to rename the receiver on CheckHeapObject, because we
don't canonicalize numbers in SignedSmall range, and thus we
the representation selection can hand out TaggedSigned values
for receiver uses, even though we checked for TaggedPointerness
first.
Note that this is rather hacky and just intended to fix the bug
ASAP. We need to think about how to deal with representations in
earlier compilation stages.
BUG=chromium:662410
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2485563002
Cr-Commit-Position: refs/heads/master@{#40792}
Using _exit on windows may cause race conditions in threads.
BUG=chromium:603131
Review-Url: https://codereview.chromium.org/2478473003
Cr-Commit-Position: refs/heads/master@{#40789}
This adds support to track Float64 fields on 64-bit platforms, which is
necessary to properly deal with unboxed double fields there.
Drive-by-fix: Crash if we see Simd128 representation here.
R=jarin@chromium.org
BUG=v8:5608
Review-Url: https://codereview.chromium.org/2485543002
Cr-Commit-Position: refs/heads/master@{#40788}
In Crankshaft we unconditionally assume that accesses to arguments[i] will
be in-bounds and don't take into account IC feedback that would eventually
teach us about out-of-bounds accesses that have happened in the past, so
there's no real guard to protect the bounds check in optimized code.
TEST=mjsunit/compiler/deopt-arguments-oob
R=jarin@chromium.org
BUG=v8:5606
Review-Url: https://codereview.chromium.org/2481053002
Cr-Commit-Position: refs/heads/master@{#40787}
Reason for revert:
Speculative revert for blocking roll:
https://codereview.chromium.org/2473003006/
E.g.:
https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_rel_ng/builds/331898
Original issue's description:
> [Tracing] Use TracingCategoryObserver in gc statistics
>
> This patch is a follow-up patch to enable gc statistics to use
> TracingCategoryObserver.
>
> Previously we need to pass --track_gc_object_stats to v8 if we want to enable
> gc statistics in tracing. In this patch, we introducce an integer flag
> FLAG_gc_stats, and FLAG_track_gc_object_stats and FLAG_trace_gc_object_stats
> will set it to 0x01, tracing will set it to 0x10 when we start tracing and
> reset the bit when we stop tracing.
>
> BUG=v8:5590
TBR=fmeawad@chromium.org,mlippautz@chromium.org,lpy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5590
Review-Url: https://codereview.chromium.org/2477143002
Cr-Commit-Position: refs/heads/master@{#40785}
This method iterates through all shared function info which are related to passed script, compiles debug code for SFI in range if needed and returns possible break locations.
BUG=chromium:566801
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
Review-Url: https://codereview.chromium.org/2465553003
Cr-Commit-Position: refs/heads/master@{#40783}
This patch fixes two bugs in V8 to allow the global object to have a frozen proto:
- The immutable prototype map check is done on the map of the "real receiver",
the one that's found after the hidden prototype traversal, rather than
the object that SetPrototype is called on.
- The immutable prototype bit from the ObjectTemplate used to instantiate
the global object, as passed to Context::New, is respected when instantiating
the global object.
R=adamk
BUG=v8:5149
Review-Url: https://codereview.chromium.org/2474843003
Cr-Commit-Position: refs/heads/master@{#40778}
This patch is a follow-up patch to enable gc statistics to use
TracingCategoryObserver.
Previously we need to pass --track_gc_object_stats to v8 if we want to enable
gc statistics in tracing. In this patch, we introducce an integer flag
FLAG_gc_stats, and FLAG_track_gc_object_stats and FLAG_trace_gc_object_stats
will set it to 0x01, tracing will set it to 0x10 when we start tracing and
reset the bit when we stop tracing.
BUG=v8:5590
Review-Url: https://codereview.chromium.org/2459903003
Cr-Commit-Position: refs/heads/master@{#40777}
This removes the deprecated flag in question which has been enabled by
default a while ago. All components can by now deal with activations of
a single function being mixed between Ignition and other compilers. The
maintenance overhead to support a mode that clears bytecode is no longer
warranted.
R=rmcilroy@chromium.org
BUG=v8:4280
Review-Url: https://codereview.chromium.org/2475203003
Cr-Commit-Position: refs/heads/master@{#40776}
Compatible with the current (unshipped) Blink implementation.
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2471923002
Cr-Commit-Position: refs/heads/master@{#40775}
If a HeapObject field is 8 bytes long and 8 bytes aligned, but we use only four bytes of it
on little endian architectures we will access to lower 4 bytes of the field using the same
base address as accessing the whole eight bytes
On big-endian architectures however we use base address to access the full 8 bytes, but base
address + 4 to access to lower 4 bytes. For this reason, the assert in OffsetForFieldAccess
fails on MIPS64 big endian.
We fix the issue by removing the assert that checks that offset is pointer size aligned.
TEST=mjsunit/regress/regress-crbug-648737
BUG=
Review-Url: https://codereview.chromium.org/2453333002
Cr-Commit-Position: refs/heads/master@{#40772}
Parameters of a lazily parsed function used to be parsed eagerly, and parameter
handling was split between Parser::ParseFunctionLiteral and
ParseEagerFunctionBody, leading to inconsistencies.
After this CL, we preparse (lazy parse) the parameters of lazily parsed
functions.
(For arrow functions, we cannot do that ofc.)
This is needed for later features (PreParser with scope analysis).
-- CL adapted from marja's https://codereview.chromium.org/2411793003/
BUG=
Review-Url: https://codereview.chromium.org/2472063002
Cr-Commit-Position: refs/heads/master@{#40771}
Reason for the failure is that the test enumeration is 32-bit wide, whereas
AtomicWord is 64-bit wide on 64-bit machines. On 64-big endian, this loads the random four bytes located after the 32-bit value that is tested.
BUG=
TEST=unittests/NoBarrierAtomicValue.Construction
Review-Url: https://codereview.chromium.org/2464703003
Cr-Commit-Position: refs/heads/master@{#40767}
- Remove (one version of) InterpreterAssembler::LoadContextSlot in favor of the
identical CodeStubAssembler::LoadContextElement.
- Use CodeStubAssembler::LoadNativeContext instead of doing the load manually.
R=rmcilroy@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2470253003
Cr-Commit-Position: refs/heads/master@{#40766}
Some accessors requires little to no computation at all, its result can be
cached in a private property, avoiding the call overhead.
Calls to the getter are translated into a cheap property load.
Follow-on to crrev.com/2347523003, from peterssen@google.com
BUG=chromium:634276, v8:5548
Review-Url: https://codereview.chromium.org/2405213002
Cr-Commit-Position: refs/heads/master@{#40765}
Fix 4447405b17
A typo in the patch caused failures on MIPS64. There were no failures on MIPS32,
but I guess the same patch needs to be applied there as well.
BUG=
Review-Url: https://codereview.chromium.org/2473343002
Cr-Commit-Position: refs/heads/master@{#40763}
When checking for marking a function for optimization, we had a check if
the function is already optimized to return early. This works in non-OSR
cases. For Turbofan OSR even when the current execution of the function
has already been optimized, the function itself will not be replaced
with optimized code. Hence, we may end up checking a function that is
already marked for optimization again. A check for the frame being optimized
avoids these checks.
BUG=
Review-Url: https://codereview.chromium.org/2450233002
Cr-Commit-Position: refs/heads/master@{#40760}
Port f07d2cdd6a
Original commit message:
A load instruction will implicitely clear the top 32 bits when writing to a W
register. This patch avoids generating a `mov` instruction to zero-extend the
result in this case.
For example, this occurs in the generated code for dispatching to the next
bytecode in the interpreter:
kind = BYTECODE_HANDLER
name = LdaZero
compiler = turbofan
Instructions (size = 36)
0x32e64c60 0 add x19, x19, #0x1 (1)
0x32e64c64 4 ldrb w0, [x20, x19]
0x32e64c68 8 mov w0, w0
^^^^^^^^^^
0x32e64c6c 12 lsl x0, x0, #3
0x32e64c70 16 ldr x1, [x21, x0]
0x32e64c74 20 movz x0, #0x0
0x32e64c78 24 br x1
Review-Url: https://codereview.chromium.org/2469253002
Cr-Commit-Position: refs/heads/master@{#40758}
The value numbering reducer has collision checks for nodes that mutated,
but kept the same hash, and are now equivalent to another node. However,
it can also accidentally hit itself, if it mutated, changed hash, but
ran over the location it was previously in.
After this patch, it checks to see if it is comparing against itself,
and skips over itself. Additionally, if this check is at the end of the
collisions, it opportunistically removes the duplicate entry and reduces
the size pressure on the list. We can do the same opportunistic clean up
if we happen to find a colliding equivalent entry, since we move it from
its original position to a new one.
Drive-by change: Ensure that the collision replacement checks types in
the same way that normal replacement does.
Review-Url: https://codereview.chromium.org/2475653002
Cr-Commit-Position: refs/heads/master@{#40757}
