There remained a few of regressions and we didn't see any significant
improvement in the real world with this turned on. This CL reverts all the
StringConcat bytecode work which landed.
BUG=v8:6243
Change-Id: I832eb72e880ad41411dbec8fe29f71ef0f2025c8
Reviewed-on: https://chromium-review.googlesource.com/575130
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46769}
Returning a double from ToFloat64 could lead to problems. If value_ has the bit
representation of a signaling NaN (sNaN), then returning it as double can cause
the signaling bit to flip, and value_ is returned as a quiet NaN (qNaN).
The usage of the Double wrapper also, makes the function ToFloat64AsInt
redundant, since the Double wrapper already has the AsUint64() method,
which returns an uint64_t.
R=ahaas@chromium.org
Change-Id: I1e627b97b2fb6110fc702fe58f2b83eb343e9ca2
Reviewed-on: https://chromium-review.googlesource.com/563215
Commit-Queue: Enrico Bacis <enricobacis@google.com>
Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46680}
There is just one version now, called IsPowerOfTwo. It accepts any
integral type.
There is one slight semantical change: Called with kMinInt, it
previously returned true, because the argument was implicitly casted to
an unsigned. It's now (correctly) returning false, so I had to add
special handlings of kMinInt in machine-operator-reducer before calling
IsPowerOfTwo on that value.
R=mlippautz@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org,ishell@chromium.org,yangguo@chromium.org
Change-Id: Idc112a89034cdc8c03365b778b33b1c29fefb38d
Reviewed-on: https://chromium-review.googlesource.com/568140
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46627}
This CL moves collected source range information out of AST nodes
and into a side table stored on ParseInfo. The side table is only
created if block coverage is enabled, so there's almost no memory
overhead in the standard case.
Change-Id: I41871b8425ebbc6217d82d3ad26b5fc9e5d68ecb
Reviewed-on: https://chromium-review.googlesource.com/566808
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46590}
Each reducer now has a virtual reducer_name function, returning its name
(the name of the class containing this reducer). This gets displayed when
using the --trace_turbo_reduction flag. Also when using this flags more
messages are displayed.
Actually when a node is replaced in-place (which is called an update
of the node), other reducers can still update it right after the
in-place replacement. When a node is really replaced (not in-place),
then we stop trying to apply reducers to it before we propagate the
reduction through the relevant nodes.
Before a message got printed only for the last reduction it went
through. So in case a node was reduced in-place several times
in a row, only the last update was printed, or none at all if after
being reduced in-place it got reduced by being replaced by another
node: only the non-in-place replacement was showed.
Now each time an in-place reduction is applied to a node, a message
gets printed.
Bug:
Change-Id: Id0f816fecd44c01d0253966c6decc4861be0c2fa
Reviewed-on: https://chromium-review.googlesource.com/563365
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Alexandre Talon <alexandret@google.com>
Cr-Commit-Position: refs/heads/master@{#46552}
On Loongson 3A, MADD/MSUB instructions are actually fused MADD/MSUB and
they can cause failure in some of the tests. Since this optimization is
rarely used, and not used at all on MIPS64R6, MADD/MSUB instructions
are removed from the source base.
TEST=
BUG=
Change-Id: Ifbb5508a62731bb061f332864ffd1e210e97f963
Reviewed-on: https://chromium-review.googlesource.com/558066
Reviewed-by: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Cr-Commit-Position: refs/heads/master@{#46387}
With FCG no longer able to deoptimize, we can remove the "push" version
of output frame state combine, as deoptimisation to bytecode is always
the PokeAt variant.
Bug: v8:6409
Change-Id: I9b6d38a7441ca834835615c238228fa8a75a027b
Reviewed-on: https://chromium-review.googlesource.com/557866
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46355}
This removes support for reconstructing stack frames for full-codegen
from the deoptimizer. We no longer deoptimize to such code. This also
allows us to remove the {DeoptimizationOutputData} data structure.
R=jarin@chromium.org
BUG=v8:6409
Change-Id: Id28ef05aa985b6877b5c91926a7d7d0d6d6e661d
Reviewed-on: https://chromium-review.googlesource.com/535537
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45943}
The AST-based graph builder is by now only used for asm.js code. This
change hard-codes this assumption into the compilation pipeline and
hence allows us to remove support pertaining to deoptimization from
optimized code that was not derived from bytecode.
R=jarin@chromium.org
BUG=v8:6409
Change-Id: I1138f16f663db5b9ee34e3110184067b8fcffc8b
Reviewed-on: https://chromium-review.googlesource.com/531026
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45887}
Adds support for lowering of ToPrimitiveToString and StringConcat bytecodes
to the corresponding builtins. As part of this, moves the interpreter
implementation of these operations into the appropriate builtin generators
and add builtin support for them.
Also adds TailCallRuntimeN operator to code-assembler which enables tail calling
a runtime function when the arguments have already been pushed onto the stack.
BUG=v8:6243
Change-Id: Id5c851bc42e4ff490d9a23a8990ae331c7eac73e
Reviewed-on: https://chromium-review.googlesource.com/515362
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45756}
Rather than trying to pre-calculate the number of contexts required during
scope analysis, instead just allocate context registers in the register
allocator. This reduces frame size a bit due to reusing of registers when
the context isn't pushed.
BUG=v8:6322, chromium:716265
Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89
Reviewed-on: https://chromium-review.googlesource.com/514087
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45522}
Reland d8bfdb7a99
Original commit message:
If alignment parameter is set, the memory returned by the
StackSlot operator will be aligned according to the parameter.
The implementation goes like this. If alignment parameter is set
we allocate a bit more memory than actually needed and so we
can move the beginning of the StackSlot in order to have it aligned.
BUG=
Review-Url: https://codereview.chromium.org/2874713003
Cr-Commit-Position: refs/heads/master@{#45339}
Introduce a new SwitchSmiTable bytecode for generators, which does a
table lookup for the accumulator value in a jump table stored in the
constant array pool. This removes the if-else chains at resumable
function/loop headers.
As a drive-by, add a scoped environment saving struct to the bytecode
graph builder.
Bug: v8:6351
Bug: v8:6366
Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0
Reviewed-on: https://chromium-review.googlesource.com/500271
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45314}
Intrinsic and generic lowering for generator object creation. In a follow-on, create lowering will be addressed.
BUG=v8:6352
Review-Url: https://codereview.chromium.org/2862213002
Cr-Commit-Position: refs/heads/master@{#45171}
When the incoming value to ChangeFloat64ToTagged is in Smi range, we
represent it as Smi instead of a HeapNumber. This addresses a range of
problems where TurboFan unnecessarily deoptimizes because an operation
learned Smi feedback in Ignition, but was then confronted with a tagged
HeapNumber in TurboFan, just because the value was also represented as
unboxed double somewhere in the meantime.
BUG=v8:6256
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2815283002
Cr-Commit-Position: refs/heads/master@{#44631}
All the optimizations have now been moved to either the BytecodeGenerator
or the BytecodeArrayWriter/Builder.
BUG=v8:6194
Change-Id: Ie5c5d55e824c94ffb503af376c72bc64ad1f6f81
Reviewed-on: https://chromium-review.googlesource.com/469349
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44564}
Moves the logic for eliding non-effectful accumulator load elision from the
peephole optimizer to the BytecodeArrayWriter.
BUG=v8:6194
Change-Id: I05fbe4ee8ac340e5c355285d0b47e4a9d52fd0a8
Reviewed-on: https://chromium-review.googlesource.com/469828
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44560}
This gives us more precise type information, so we can avoid some type
guards to refine the type information back.
The motivation for this is to help escape analysis by not introducing
redundant type guards (which escape analysis cannot handle yet even
though it could and should do).
Motivating example:
In the example below, the out-of-object property array for properties
fld5 and fld6 gets type Any when it is created by "o.fld5 = 5" (for
object literals, we store 4 properties in-objeca, the rest goes out
of object).
When we run load elimination for the load the out-of-object property
array (to store 6 into o.fld6), load elimination inserts TypeGuard to
enforce the Type::Internal() type. This makes escape analysis bail out
on this object, and we do not eliminate the object creation.
function f() {
var o = {};
o.fld1 = 1;
o.fld2 = 2;
o.fld3 = 3;
o.fld4 = 4;
o.fld5 = 5;
o.fld6 = 6;
}
f();
f();
%OptimizeFunctionOnNextCall(f);
f();
Review-Url: https://codereview.chromium.org/2797993006
Cr-Commit-Position: refs/heads/master@{#44470}
Move the ToBoolean elision in the BytecodeGenerator instead of the
peephole optimizer. Adds a TypeHint mechanism to the ExpressionResult
to enable passing of type hints through the ast visitor.
BUG=v8:6194
Change-Id: Ic55506ba11b213f7459250004d3f18cab04ee9b3
Reviewed-on: https://chromium-review.googlesource.com/467208
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44415}
This handles non-strict equality comparison operations having number
feedback during the early type-hint lowering (i.e. during graph
construction).
R=jarin@chromium.org
Change-Id: I1db67e78312934bbb20aee775979797420ff2581
Reviewed-on: https://chromium-review.googlesource.com/455796
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43824}
This changes the IR to no longer require single {IfSuccess} projection
nodes unless there is a corresponding {IfException} node that links the
potentially throwing call to an exception handler. This reduces graph
size as well as compilation time when exception handlers aren't present.
The new invariant for potentially throwing nodes is: Nodes that can
potentially throw either have both IfSuccess/IfException projections as
the only control uses and no direct control uses, or no projections at
all and solely direct control uses.
R=jarin@chromium.org
Change-Id: I3d9cd816d74ad5af13e0673da7ec7a98f1ecdc7e
Reviewed-on: https://chromium-review.googlesource.com/449715
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43814}
With this change, on ia32 and x64, a load from memory into a register can be replaced by a memory operand for integer binops if it makes sense.
BUG=
Review-Url: https://codereview.chromium.org/2728533003
Cr-Commit-Position: refs/heads/master@{#43739}
Fix two issues in the interpreter entry for 64 bit return values on
32 bit platforms. First, the effect chain was slightly incorrect, second
the order of the returned values was wrong.
Also add a test case for this.
Tested on x64, ia32 and s390.
Plus drive-by fix in Int64Lowering to reuse global constants for
big-endian/little-endian disambiguation.
R=titzer@chromium.org
BUG=v8:5822
Review-Url: https://codereview.chromium.org/2731713002
Cr-Commit-Position: refs/heads/master@{#43654}
So far we only recognize the special
NumberFloor(NumberDivide(lhs, rhs))
subgraph when both lhs and rhs are in the Unsigned32 range, and the
result is a PlainNumber. Extend this pattern matching to also cover
NumberFloor(SpeculativeNumberDivide(lhs, rhs))
and to replace the NumberFloor with NumberToInt32 truncation if the
lhs value is in Signed32 range and the rhs is in Unsigned32 range.
R=jarin@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2739573004
Cr-Commit-Position: refs/heads/master@{#43642}
The parser already changes all negative equality comparison operations
to their positive pendants in {ParserBase::ParseBinaryExpression}. No
other source of the Token::NE exists in the system. We can remove all
handling from the compiler and interpreter backends.
R=bmeurer@chromium.org
Change-Id: I58722c08dd8e498f20c65886fce86b8172737b10
Reviewed-on: https://chromium-review.googlesource.com/449716
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43627}
We don't need the JSStrictNotEqual operator in the compiler, because
this is never generated by the BytecodeGraphBuilder, and the code in
the AstGraphBuilder was dead code. Also remove the backing builtin
StrictNotEqual.
R=mstarzinger@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2727003006
Cr-Commit-Position: refs/heads/master@{#43594}
We can compile a !== a and Number.isNaN(a) to ObjectIsNaN. The former is
commonly used to check for NaN, i.e. in case of equals in AngularJS.
R=jarin@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2722483003
Cr-Commit-Position: refs/heads/master@{#43572}
The x64 side is included in https://chromium-review.googlesource.com/c/444226/
BUG=v8:5294
Change-Id: Ie255604c5e38c72e3c2b76e1ca3557a5fde108ee
Reviewed-on: https://chromium-review.googlesource.com/446394
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43481}
This extends the existing typer for JS-level comparisons to also be
applied on simplified-level number comparisons. Now that nodes having
such operators are introduced early during graph construction, precise
type information has become more important.
R=jarin@chromium.org
TEST=unittests/TyperTest
Change-Id: Ibcfda36cadf72381b3c63138dd8ad2f6b1f7fbba
Reviewed-on: https://chromium-review.googlesource.com/445879
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43447}
Nodes having the {Throw} operator are just used as terminators for
control-flow leaving the function body with an exception completion,
they turn into basic-block terminators within the schedule. Actually
raising an exception is done solely via runtime calls. Hence {Throw}
nodes no longer need any value input.
R=bmeurer@chromium.org
Change-Id: Id6d8e46b12c4b84f4e7a8ac96623c8efb1f27b26
Reviewed-on: https://chromium-review.googlesource.com/446501
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43445}
Enable using BaseWithIndexAndDisplacement addressing mode for an address
used by multiple load/stores. It can reduce one instruction to calculate
the address and one register to store the address.
BUG=
Review-Url: https://codereview.chromium.org/2620293004
Cr-Commit-Position: refs/heads/master@{#43402}
This handles arithmetic addition operations during the early type-hint
lowering (i.e. during graph construction). The string addition case is
still handled by {JSTypedLowering} as it needs static type information.
R=bmeurer@chromium.org
Change-Id: I9df47dfc5bf7613c51f6d803ab43d5d3f6c21be8
Reviewed-on: https://chromium-review.googlesource.com/443185
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43235}
This handles all arithmetic binary operations except addition during the
early type-hint lowering (i.e. during graph construction). We still use
static type information to potentially further reduce the speculative
operations down to pure operations during the typed lowering phase.
R=bmeurer@chromium.org
Change-Id: I8b93fd7c46ec8e5b81234a49624d503520c3d082
Reviewed-on: https://chromium-review.googlesource.com/443105
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43218}
This allows part of typed lowering that is solely based on type-hints to
run as part of the graph construction. The lowering in question does not
inspect types and hence doesn't require the typer to have run before. We
insert the speculative simplied-level operations in favor of the generic
JavaScript-level variants.
R=bmeurer@chromium.org
Change-Id: I5f0549fc1e4ff607622ee9059e6232a32f77db2e
Reviewed-on: https://chromium-review.googlesource.com/442584
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43208}
This introduces new maps to track whether we have created at most one
closure. If we have created just one closure, Turbofan will
specialize the code to its context.
Review-Url: https://codereview.chromium.org/2680313002
Cr-Commit-Position: refs/heads/master@{#43108}
Since the empty string is canonical HeapObject now, we can use
this fact to optimize
- strict equality comparisons with the empty string to a
simple ReferenceEqual operation, and
- optimize ToBoolean to avoid instance type checks completely.
Drive-by-fix: Allow InternalizedString for Type::HeapConstant
in the type system. This is safe, since InternalizedStrings
can be compared to other heap constants by reference (except
for non-InternalizedStrings, which are excluded from the
HeapConstant type).
BUG=v8:5267
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2681273002
Cr-Commit-Position: refs/heads/master@{#43050}
Arm64 compiles "x +_64 (y >> shift)" into a single instruction if
"shift" is a constant. The code generator expects that "shift" is a
32 bit constant. however, TurboFan can also pass in a 64 bit constant,
which caused a crash in the code generator.
With this CL we cast the constant of TurboFan to an int in the
instruction selector and thereby satisfy the assumption of the code
generator. This should be correct since the code generator anyways cast
the "shift" to an int5 or int6 eventually.
R=v8-arm-ports@googlegroups.com
BUG=v8:5923
Review-Url: https://codereview.chromium.org/2669203005
Cr-Commit-Position: refs/heads/master@{#43036}
