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}
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
Review-Url: https://codereview.chromium.org/2184553003
Cr-Commit-Position: refs/heads/master@{#38044}
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
Review-Url: https://codereview.chromium.org/2172233002
Cr-Commit-Position: refs/heads/master@{#38043}
This flag is aiming at shipping the ability to generate optimized code
directly from bytecode (without re-parsing source code). All features
needed to ship such a configuration will be staged behind this flag.
R=hablich@chromium.org,rmcilroy@chromium.org
Review-Url: https://codereview.chromium.org/2174333002
Cr-Commit-Position: refs/heads/master@{#38040}
This test fails because WasmGraphBuilder::BuildCFuncInstruction allocates
space for doubles using StackSlot turbofan operator, but this space is not
guaranteed to be 8 bytes aligned if SP itself is not 8 bytes aligned (which
is the case on 32-bit architectures).
BUG=mjsunit/wasm/embenchen/box2d
Review-Url: https://codereview.chromium.org/2177863002
Cr-Commit-Position: refs/heads/master@{#38039}
When we eliminate nodes during truncation analysis that have no value
uses, we must make sure that we do not eliminate speculative number
operations that would have side effects depending on the inputs, i.e.
for example a SpeculativeNumberMultiply(x,y) does ToNumber(x) and
ToNumber(y) first, so if either x or y could throw an exception during
ToNumber conversion, we must not eliminate the multiplication, even if
it has no value uses (some later pass may kill the actual machine
multiplication, but the checks on the inputs have to remain still).
So we check whether both x and y are PlainPrimitive, i.e. neither
Receiver nor Symbol, which could raise exceptions for ToNumber, and
only in that case we propagate the "unusedness" of the node to its
inputs.
This also uncovered a bug with the type of Dead, which must be None,
as this represents an impossible value, so we had to fix that too.
Also the dead code removal will not work correctly for constants (i.e.
pure nodes with no value inputs), as those might be cached and hence
we might resurrect them for an unrelated node lowering during
SimplifiedLowering and only later kill the actual node (replacing its
uses with Dead), which would then also replace the new use with Dead.
So that was fixed as well. This shouldn't change anything for the
result, as unused constants automagically disappear from the graph later
on anyways.
R=yangguo@chromium.org
BUG=chromium:631318
Review-Url: https://codereview.chromium.org/2182003002
Cr-Commit-Position: refs/heads/master@{#38038}
Reason for revert:
This bug has an error in the toolchain.gypi file, the conditions clause is repeated. This has broken the DrMemory builder - see first failing chromium build https://build.chromium.org/p/chromium.memory.fyi/builders/Chromium%20Windows%20Builder%20%28DrMemory%29/builds/17857 which included a v8 roll.
For reference the errors are:
gyp: Key 'conditions' repeated at level 11 with key path 'target_defaults.conditions.6.1.target_conditions.0.1.conditions.0.1' while reading C:\b\build\slave\drm-cr\build\src\v8\gypfiles\toolchain.gypi while reading includes of C:\b\build\slave\drm-cr\build\src\v8\src\d8.gyp
gyp: Key 'conditions' repeated at level 11 with key path 'target_defaults.conditions.6.1.target_conditions.0.1.conditions.0.1' while reading C:\b\build\slave\drm-cr\build\src\v8\gypfiles\toolchain.gypi while reading includes of C:\b\build\slave\drm-cr\build\src\v8\src\v8.gyp
gyp: Key 'conditions' repeated at level 11 with key path 'target_defaults.conditions.6.1.target_conditions.0.1.conditions.0.1' while reading C:\b\build\slave\drm-cr\build\src\v8\gypfiles\toolchain.gypi while reading includes of C:\b\build\slave\drm-cr\build\src\v8\samples\samples.gyp
Original issue's description:
> MIPS: Fix '[turbofan] Prevent storing signalling NaNs into holey double arrays.'
>
> Port 6470ddadf9
>
> On MIPS different signaling NaN values must be used for hardware and simulator targets, even at snapshot generation when always simulator is used.
>
> Original commit message:
> 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=
>
> Committed: https://crrev.com/52f2ceb052f63324050c7a098e4398f510b54763
> Cr-Commit-Position: refs/heads/master@{#38030}
TBR=jarin@chromium.org,machenbach@google.com,akos.palfi@mattakis.com,ivica.bogosavljevic@imgtec.com,marija.antic@imgtec.com,ilija.pavlovic.imgtec@gmail.com,akos.palfi@imgtec.com,machenbach@chromium.org,balazs.kilvady@imgtec.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
TBR=machenbach
Review-Url: https://codereview.chromium.org/2184573002
Cr-Commit-Position: refs/heads/master@{#38037}
Rolling v8/build to cce24bcaab6481f479f4baf00b5ea36d78268bcd
Rolling v8/tools/mb to 11aa1bbe1b4fbae3694d14eb59b4eb98550bcbee
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review-Url: https://codereview.chromium.org/2181913002
Cr-Commit-Position: refs/heads/master@{#38036}
This slightly simplifies scope handling. It also makes it possible to
implement some potential future changes to classes purely in the parser
by adding additional code to the DoExpression.
This is a portion of https://codereview.chromium.org/2142333002/, which
probably isn't going through in full.
Review-Url: https://codereview.chromium.org/2176653003
Cr-Commit-Position: refs/heads/master@{#38035}
