Objects that reside below the age mark could be on pages that have been moved
within new space. In this case mementos survived which can actually point to
already-collected allocation sites.
BUG=chromium:631050,chromium:581412
R=hpayer@chromium.org
Review-Url: https://codereview.chromium.org/2179033005
Cr-Commit-Position: refs/heads/master@{#38094}
Inline XxxIC::initialize_stub_in_optimized_code() methods to CodeFactory and use stub's call interface descriptor instead of hard-coded one.
BUG=v8:5236
Review-Url: https://codereview.chromium.org/2184063002
Cr-Commit-Position: refs/heads/master@{#38093}
Reason for revert:
Breaks roll: https://codereview.chromium.org/2182043004/
Original issue's description:
> [gn] Don't use PIE for host executables
>
> Using PIE switches on ASLR. With mksnapshot, this can lead
> to non-deterministic snapshots.
>
> BUG=v8:5233
>
> Committed: https://crrev.com/4ca39b53245619d94a80a93939613774e68e4649
> Cr-Commit-Position: refs/heads/master@{#38084}
TBR=jochen@chromium.org,vogelheim@chromium.org,yangguo@chromium.org,machenbach@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5233
Review-Url: https://codereview.chromium.org/2187613003
Cr-Commit-Position: refs/heads/master@{#38092}
This leads to a better handling of the Smi case when we introduce a checked truncation from a number or oddbal to a 32 bit word, which we were previously doing by concatenating a Smi to float64 conversion with a float64 to word32 truncation.
BUG=
Review-Url: https://codereview.chromium.org/2191503002
Cr-Commit-Position: refs/heads/master@{#38091}
Port 52f2ceb052
Original commit message:
On MIPS different signaling NaN values must be used for hardware and simulator targets, even at snapshot generation when always simulator is used.
This introduces SilenceNaN operator, which makes sure that we only
store quiet NaNs into holey arrays. We omit the NaN silencing code
at instruction selection time if the input is an operation that
cannot possibly produce signalling NaNs.
BUG=
TEST=mjsunit/compiler/regress-store-holey-double-array
Review-Url: https://codereview.chromium.org/2188433002
Cr-Commit-Position: refs/heads/master@{#38090}
Also run the BranchElimination (plus CommonOperatorReducer and the
DeadCodeElimination) during the load elimination phase, so we can
elminate some Phi nodes early on that would otherwise confuse the
truncation analysis and/or representation selection, i.e. if there's a
branch that is never taken, that would yield undefined, we'd have to
choose tagged representation for the Phi, even if the always taken
branch yields an integer.
R=epertoso@chromium.org
BUG=v8:4930,v8:5141
Review-Url: https://codereview.chromium.org/2190543002
Cr-Commit-Position: refs/heads/master@{#38088}
This required the introduction of the CheckedNumberOrOddballAsWord32 use info, and a change in the RepresentationChanger to handle it.
BUG=
Review-Url: https://codereview.chromium.org/2184513003
Cr-Commit-Position: refs/heads/master@{#38086}
Using PIE switches on ASLR. With mksnapshot, this can lead
to non-deterministic snapshots.
BUG=v8:5233
Review-Url: https://codereview.chromium.org/2179303003
Cr-Commit-Position: refs/heads/master@{#38084}
This implements graph construction for entry via on-stack replacement
within the {BytecodeGraphBuilder}. Entry points are at loop headers
similar to previous OSR implementations. All interpreter registers are
addressable via {OsrValue} nodes in the graph. Currently we rely on
{OsrPoll} bytecodes to be placed right after loop headers (i.e. at the
targets of back edges).
R=jarin@chromium.org
BUG=v8:4764
Review-Url: https://codereview.chromium.org/2171083004
Cr-Commit-Position: refs/heads/master@{#38083}
This CL fixed one bug in crankshaft compiler for Math.max(-0, 0).
BUG=
Review-Url: https://codereview.chromium.org/2175243002
Cr-Commit-Position: refs/heads/master@{#38079}
The new phase will detect loop variable, infer bounds and bake them into
the type.
Review-Url: https://codereview.chromium.org/2164263003
Cr-Commit-Position: refs/heads/master@{#38077}
Introduce the CheckString during native context specialization when we
have string map feedback on a LOAD_IC/STORE_IC. The CheckString
operator, just like its CheckNumber pendant, renames the input and
assigns a proper type, which we will use soon to lower access operations
on Strings, i.e. charCodeAt calls or keyed accesses.
R=jarin@chromium.org
BUG=v8:4930,v8:5141
Review-Url: https://codereview.chromium.org/2181943003
Cr-Commit-Position: refs/heads/master@{#38076}
Rolling v8/build to 603acacfd82e28d442da5e24bf22bbacbeefa589
Rolling v8/buildtools to 67bf0653b2eb9eabd4fc17c4bf2df828e904a558
Rolling v8/third_party/android_tools to af1c5a4cd6329ccdcf8c2bc93d9eea02f9d74869
Rolling v8/tools/clang to a98f7fa326ac2b7e1710e923c1287cde7f901d86
Rolling v8/tools/mb to 93a755bd710560a2db62300d69db0d8876c01442
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review-Url: https://codereview.chromium.org/2191433002
Cr-Commit-Position: refs/heads/master@{#38075}
Reason for revert:
Revert this CL due to V8 Arm Builder failure and V8 Mips Builder failure.
https://build.chromium.org/p/client.v8.ports/builders/V8%20Arm%20-%20builder/builds/2456https://build.chromium.org/p/client.v8.ports/builders/V8%20Mips%20-%20builder/builds/2506
Original issue's description:
> [Tracing] V8 Tracing Controller
>
> V8 has had a trace event macro interface for while, but without a tracing
> controller a standalone V8 would be unable to collect traces.
>
> This CL introduces a complete Tracing Controller system for V8.
> It is fully function except that it does not yet store trace event args.
>
> This CL has a few components,
> The tracing controller itself, contributed by the author of this CL
> The Trace config (including the parser), contributed by lpy@
> The Trace Object, Trace Writer, and Trace Buffer are all contributed by rksang@
>
> BUG=v8:4561
> LOG=N
>
> Committed: https://crrev.com/3d598452679ce208ad9b2f48e0fb3fae352ce375
> Cr-Commit-Position: refs/heads/master@{#38073}
TBR=jochen@chromium.org,mattloring@google.com,rskang@google.com,yangguo@chromium.org,fmeawad@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4561
Review-Url: https://codereview.chromium.org/2183943002
Cr-Commit-Position: refs/heads/master@{#38074}
V8 has had a trace event macro interface for while, but without a tracing
controller a standalone V8 would be unable to collect traces.
This CL introduces a complete Tracing Controller system for V8.
It is fully function except that it does not yet store trace event args.
This CL has a few components,
The tracing controller itself, contributed by the author of this CL
The Trace config (including the parser), contributed by lpy@
The Trace Object, Trace Writer, and Trace Buffer are all contributed by rksang@
BUG=v8:4561
LOG=N
Review-Url: https://codereview.chromium.org/2137013006
Cr-Commit-Position: refs/heads/master@{#38073}
Reason for revert:
breaks android build due to uninitialized variable.
https://build.chromium.org/p/client.v8.ports/builders/V8%20Arm%20-%20debug%20builder/builds/2034
Original issue's description:
> [debugging] print ranges for consecutive values with %DebugPrint
>
> With this CL repeated values in elements are combined into a single printout with a range.
>
> BEFORE:
> - elements = {
> 0: <undefined>
> 1: <undefined>
> 2: <the_hole>
> }
>
> AFTER:
> - elements = {
> 0-1: <undefined>
> 2: <the_hole>
> }
>
> BUG=
>
> Committed: https://crrev.com/ec4165742088043d8fede38db21a281e16682adb
> Cr-Commit-Position: refs/heads/master@{#38069}
TBR=yangguo@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review-Url: https://codereview.chromium.org/2181093003
Cr-Commit-Position: refs/heads/master@{#38071}
With this CL repeated values in elements are combined into a single printout with a range.
BEFORE:
- elements = {
0: <undefined>
1: <undefined>
2: <the_hole>
}
AFTER:
- elements = {
0-1: <undefined>
2: <the_hole>
}
BUG=
Review-Url: https://codereview.chromium.org/2169143003
Cr-Commit-Position: refs/heads/master@{#38069}
The showed up unnaturally high while profiling DOM node creation.
BUG=chromium:630217
Review-Url: https://codereview.chromium.org/2181323002
Cr-Commit-Position: refs/heads/master@{#38068}
Port 580fdf3c05
This also reverses the MachineType stored for partial unaligned access support
such that it records the unsupported types, rather than supported types.
BUG=
Review-Url: https://codereview.chromium.org/2182493003
Cr-Commit-Position: refs/heads/master@{#38065}
This adds tracking of the loop depth to the {BytecodeGenerator} in order
to statically determine the loop nesting level for {OsrPoll} bytecodes.
R=rmcilroy@chromium.org
BUG=v8:4764
Review-Url: https://codereview.chromium.org/2176183002
Cr-Commit-Position: refs/heads/master@{#38064}
Reason for revert:
Revert, because blink tryserver bot rename is reverted.
BUG=chromium:631448
Original issue's description:
> [release] Change blink trybot name on v8 roll CLs
>
> BUG=chromium:590036
> NOTRY=true
>
> Committed: https://crrev.com/a5fae1039409864295b42a6f33cef85ca9396bda
> Cr-Commit-Position: refs/heads/master@{#38041}
TBR=hablich@chromium.org,machenbach@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:590036
Review-Url: https://codereview.chromium.org/2186593003
Cr-Commit-Position: refs/heads/master@{#38062}
This is a first step towards a perfect world where a call interface descriptor is the only place that defines calling convention for a particular code stub.
Review-Url: https://codereview.chromium.org/2172223002
Cr-Commit-Position: refs/heads/master@{#38059}
Reason for revert:
Fix has been landed.
Original issue's description:
> Revert of [interpreter] Add explicit OSR polling bytecode. (patchset #6 id:100001 of https://codereview.chromium.org/2172233002/ )
>
> Reason for revert:
> Bunch of breakages. Maybe bad interaction with e520e5da55 ?
>
> E.g.:
> https://build.chromium.org/p/client.v8/builders/V8%20Linux64/builds/11607
>
> Original issue's description:
> > [interpreter] Add explicit OSR polling bytecode.
> >
> > This adds an explicit {OsrPoll} bytecode into every loop header which
> > triggers on-stack replacement when armed. Note that each such bytecode
> > stores the static loop depths as an operand, and hence can be armed for
> > specific loop depths.
> >
> > This also adds builtin code that triggers OSR compilation and switches
> > execution over to optimized code in case compilation succeeds. In case
> > compilation fails, the bytecode dispatch just continues unhindered.
> >
> > R=rmcilroy@chromium.org
> > TEST=mjsunit/ignition/osr-from-bytecode
> > BUG=v8:4764
> >
> > Committed: https://crrev.com/a55beb68e0ededb3773affa294a71edc50621458
> > Cr-Commit-Position: refs/heads/master@{#38043}
>
> TBR=rmcilroy@chromium.org,mstarzinger@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:4764
>
> Committed: https://crrev.com/439aa2c6d708bfd95db725bd6f97c4c49bbc51fc
> Cr-Commit-Position: refs/heads/master@{#38044}
TBR=rmcilroy@chromium.org,machenbach@chromium.org
BUG=v8:4764
Review-Url: https://codereview.chromium.org/2184713002
Cr-Commit-Position: refs/heads/master@{#38056}
So far we didn't really recognize leaq, but only leal instructions in
the x64 InstructionSelector. Now that we actually generate more of them,
we should also pay more attention to those.
R=epertoso@chromium.org
Review-Url: https://codereview.chromium.org/2186573002
Cr-Commit-Position: refs/heads/master@{#38055}
The bug was caused when validating expressions
X >> 0
for indexing into 8-bit heap views. If X was not an intish, the 'normal'
validation path would fail. That, however, left the type of X registered
in the AsmTyper::node_types_ member.
Later, in the 'lenient' code path for 8-bit views, the entire X >> 0
expression would be validated, which would cause X to be validated
again, at which point AsmTyper::SetTypeOf() would DCHECK because the
supplied node already had a type associated with it.
The fix was to simply FAIL() when X is not an intish. This is safe
because if X is not an intish, then
Validate(>>, !intish, FixNum)
will also fail.
BUG= https://bugs.chromium.org/p/chromium/issues/detail?id=628803
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=4203
TEST= cctest/asmjs/test-asm-typer.cc
LOG= N
Review-Url: https://codereview.chromium.org/2181723002
Cr-Commit-Position: refs/heads/master@{#38053}
This allows us to fuse the address computation with the actual memory
access operation on x64, which reduces the register pressure and the
number of instructions. There's probably some follow up cleanup that has
to happen to make sure the machine operator optimizations that are
relevant to word64 computations are also available (similar to what is
already available for word32).
R=epertoso@chromium.org
Review-Url: https://codereview.chromium.org/2183043002
Cr-Commit-Position: refs/heads/master@{#38051}
With the current approach we cannot eliminate context accesses in
mid-size function contexts, so let's bump the limit a bit to make
sure we can optimize those as well.
R=jarin@chromium.org
BUG=v8:4930,v8:5141
Review-Url: https://codereview.chromium.org/2182973004
Cr-Commit-Position: refs/heads/master@{#38050}
This works around the problem that the lowering for JSStackCheck doesn't
play well with effect chain based state tracking, because it doesn't
report the correct changes (we will address this with a better handling
of stack checks soon).
It also allows us to run the EarlyOptimizationPhase concurrently, which
doesn't need to access the heap or generate code stubs.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2183033002
Cr-Commit-Position: refs/heads/master@{#38049}
