This CL removes the Config templatization from the types. It is not
necessary anymore, after the HeapTypes have been removed.
The CL also changes the type hierarchy - the specific type kinds are
not inner classes of the Type class and they do not inherit from Type.
This is partly because it seems impossible to make this work without
templates. Instead, a new TypeBase class is introduced and all the
structural (i.e., non-bitset) types inherit from it.
The bitset type still requires the bit-munging hack and some nasty
reinterpret-casts to pretend bitsets are of type Type*. Additionally,
there is now the same hack for TypeBase - all pointers to the sub-types
of TypeBase are reinterpret-casted to Type*. This is to keep the type
constructors in inline method definitions (although it is unclear how
much that actually buys us).
In future, we would like to move to a model where we encapsulate Type*
into a class (or possibly use Type where we used to use Type*). This
would loosen the coupling between bitset size and pointer size, and
eventually we would be able to have more bits.
TBR=bradnelson@chromium.org
Review URL: https://codereview.chromium.org/1655833002
Cr-Commit-Position: refs/heads/master@{#33656}
We can constant-fold JSToNumber conversions during typed lowering
if the input is a known primitive constant (i.e. a string, oddball
or number). I.e. JSToNumber("123") can be constant-folded to 123.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1657213002
Cr-Commit-Position: refs/heads/master@{#33654}
Rolling v8/third_party/icu to 2b12f8775d66568f2b2e2bd8246efcfdff40d563
Rolling v8/tools/clang to fc5dab2a77e5a2c69f0095faba5f903d520f0bb5
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review URL: https://codereview.chromium.org/1653153003
Cr-Commit-Position: refs/heads/master@{#33653}
port cb9b801069 (r33582)
original commit message:
The previous versions of Math.max and Math.min made it difficult to
optimize those (that's why we already have custom code in Crankshaft),
and due to lack of ideas what to do about the variable number of
arguments, we will probably need to stick in special code in TurboFan
as well; so inlining those builtins is off the table, hence there's no
real advantage in having them around as "not quite JS" with extra work
necessary in the optimizing compilers to still make those builtins
somewhat fast in cases where we cannot inline them (also there's a
tricky deopt loop in Crankshaft related to Math.min and Math.max, but
that will be dealt with later).
So to sum up: Instead of trying to make Math.max and Math.min semi-fast
in the optimizing compilers with weird work-arounds support %_Arguments
%_ArgumentsLength, we do provide the optimal code as native builtins
instead and call it a day (which gives a nice performance boost on some
benchmarks).
BUG=
Review URL: https://codereview.chromium.org/1659623003
Cr-Commit-Position: refs/heads/master@{#33652}
This patch adds a UseCounter for each of the following:
- Allowing duplicate sloppy-mode block-scoped function declarations
in the exact same scope
- for-in loops with an initializer
The patch also refactors some of the declaration code to clean it up and
enable the first counter, and adds additional unit tests to nail down
the semantics of edge cases of sloppy-mode block-scoped function declarations.
BUG=v8:4693,chromium:579395
LOG=N
R=adamk
Review URL: https://codereview.chromium.org/1633743003
Cr-Commit-Position: refs/heads/master@{#33650}
Improved flexibility for the perf runner, by adding option to
specify precisely shell binary.
NOTRY=true
Review URL: https://codereview.chromium.org/1659483003
Cr-Commit-Position: refs/heads/master@{#33649}
A class's name is its constructor's name, so there's no need to treat it separately,
either in the parser or in code generation. The main parser use of the name is
for ES2015 Function.name handling, and this patch also cleans up handling there
by adding a new IsAnonymousFunctionDefinition() method to Expression (the name
comes from the spec).
Also removed unused ParserTraits::DefaultConstructor method.
BUG=v8:3699
LOG=n
Review URL: https://codereview.chromium.org/1647213002
Cr-Commit-Position: refs/heads/master@{#33643}
The runtime call to Runtime::kReThrow does not need a frame-state node
attached, the frame-state input count is zero. This restructures the
graph builder to not instantiate a FrameStateBeforeAndAfter for it.
R=jarin@chromium.org
TEST=cctest/test-run-bytecode-graph-builder
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1654833002
Cr-Commit-Position: refs/heads/master@{#33641}
The notion of an unreachable environment is useful for a recursive
descent iteration (e.g. over an AST) where nodes are created on the
ascent path as well. For a flat iteration (e.g. over bytecode stream)
environments become unreachable at the end of a visitation function.
Hence any unreachable path can be represented by nulling the tracked
environment completely. This further reduces the number of redundant
nodes being created.
R=oth@chromium.org
Review URL: https://codereview.chromium.org/1650483003
Cr-Commit-Position: refs/heads/master@{#33639}
Set the bytecode array correctly in Runtime_SetCode.
This fixes issues with building the snapshot with ignition enabled.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1647913002
Cr-Commit-Position: refs/heads/master@{#33638}
Although x87 has 8 registers, it use only 1 double register in TurboFan code generation for some limitations.
So for TestStackSlot() function, use the num_allocatable_double_registers() to check the avaliable double registers
of TurboFan is more suitable than num_double_registers().
BUG=
Review URL: https://codereview.chromium.org/1653913002
Cr-Commit-Position: refs/heads/master@{#33636}
This simplifies the branch analysis we perform on the bytecode stream
down to the bare minimum that we need to build graphs. Note that we
still record all branch targets, even though only the backwards ones
would be needed, but this is essentially for free and might be useful
eventually.
R=oth@chromium.org
Review URL: https://codereview.chromium.org/1646873004
Cr-Commit-Position: refs/heads/master@{#33635}
The reachability of a bytecode is implied by a live environment reaching
the bytecode during the abstract control flow simulation of the bytecode
iteration perfromed by the graph builder. There is no need to compute it
upfront anymore.
Also, the upfront computation was only an approximation when it came to
the reachability of an exception handler. This is why several tests for
translation of exception handlers can now be enabled.
R=oth@chromium.org
Review URL: https://codereview.chromium.org/1645293003
Cr-Commit-Position: refs/heads/master@{#33634}
This simplifies how the BytecodeGraphBuilder simulates control flow by
reversing the propagation direction to forwards propagation. This is the
same direction as the data flow which is also a forward propagation. In
this way the analysis information needed at merge points is drastically
reduced while still retaining the same simulation power.
In short: We push down environments instead of pulling them.
R=oth@chromium.org
Review URL: https://codereview.chromium.org/1641893004
Cr-Commit-Position: refs/heads/master@{#33633}
NonPatternRewrite was called more than once for the same AST
in the case of (computed) key expressions present in object
literals. As an example, in:
var x = { [[...42]]: 17 };
the array containing the spread would be desugared first and
then the resulting do-expression would again be desugared.
This could be problematic if a computed key expression contains
large nested array/object literals.
R=rossberg@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1645023002
Cr-Commit-Position: refs/heads/master@{#33632}
The CL #33347 (https://codereview.chromium.org/1589363002) added the RunRoundInt32ToFloat32 test case and X87 failed at it.
The reason is same as the CL #31808 (issue 1430943002, X87: Change the test case for X87 float operations), please refer: https://codereview.chromium.org/1430943002/.
Here is the key comments from CL #31808
Some new test cases use CheckFloatEq(...) and CheckDoubleEq(...) function for result check. When GCC compiling the CheckFloatEq() and CheckDoubleEq() function,
those inlined functions has different behavior comparing with GCC ia32 build and x87 build.
The major difference is sse float register still has single precision rounding semantic. While X87 register has no such rounding precsion semantic when directly use register value.
The V8 turbofan JITTed has exactly same result in both X87 and IA32 port.
For CHECK_EQ(a, b) function, if a and b are doubles, it will has similar behaviors like CheckFloatEq(...) and CheckDoubleEq(...) function when compiled by GCC and causes the test case
fail.
So we add the following sentence to do type case to keep the same precision for RunRoundInt32ToFloat32. Such as: volatile double expect = static_cast<float>(*i).
BUG=
Review URL: https://codereview.chromium.org/1649323002
Cr-Commit-Position: refs/heads/master@{#33630}
This patch ships the first part of RegExp subclassing--defining
Symbol.{match,replace,search,split}, but keeping their original
definitions which are restricted to a RegExp receiver and do not
call out to the core 'exec' method. This is being shipped separately
because the two sets of extension points are separate features with
separate functionality. The amount of behavior which is held behind
the flag is very small, just exposing the symbols as properties of
Symbol--the behavior that the String methods call out to these Symbol
properties has already been shipping unflagged.
R=yangguo@chromium.org
BUG=v8:4305,v8:4343,v8:4344,v8:4345
LOG=Y
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1652793002
Cr-Commit-Position: refs/heads/master@{#33629}
In the debugger we are interested in getting the context for the
current frame, which is usually a function context. To do that,
we used to call Context::declaration_context, which may also
return a block context. This is wrong and can lead to crashes.
Instead, we now use a newly introduced Context::closure_context,
which skips block contexts. This works fine for the debugger,
since we have other means to find and materialize block contexts.
R=rossberg@chromium.org
BUG=chromium:582051
LOG=N
Review URL: https://codereview.chromium.org/1648263002
Cr-Commit-Position: refs/heads/master@{#33627}
Rolling v8/base/trace_event/common to 3b14e6554b07defdad00c17d162c6e7121f71fbf
Rolling v8/buildtools to 389b7143dbd63da3a9725e304d286b02805fc170
Rolling v8/tools/clang to 7548b22debe829cb92047725def34c50fb88ca01
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review URL: https://codereview.chromium.org/1648343004
Cr-Commit-Position: refs/heads/master@{#33624}
Associate a type with foreign functions at their callsite.
Associate a type with foreign variables.
More pervasively forbid computation in the module body.
Confirm foreign call arguments are exports.
Pass zone to more Type constructors, for consistency.
BUG= https://code.google.com/p/v8/issues/detail?id=4203
TEST=test-asm-validator
R=aseemgarg@chromium.org,titzer@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/1643003004
Cr-Commit-Position: refs/heads/master@{#33622}
Port cb9b801069
Original commit message:
The previous versions of Math.max and Math.min made it difficult to
optimize those (that's why we already have custom code in Crankshaft),
and due to lack of ideas what to do about the variable number of
arguments, we will probably need to stick in special code in TurboFan
as well; so inlining those builtins is off the table, hence there's no
real advantage in having them around as "not quite JS" with extra work
necessary in the optimizing compilers to still make those builtins
somewhat fast in cases where we cannot inline them (also there's a
tricky deopt loop in Crankshaft related to Math.min and Math.max, but
that will be dealt with later).
So to sum up: Instead of trying to make Math.max and Math.min semi-fast
in the optimizing compilers with weird work-arounds support %_Arguments
%_ArgumentsLength, we do provide the optimal code as native builtins
instead and call it a day (which gives a nice performance boost on some
benchmarks).
R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
Review URL: https://codereview.chromium.org/1648353002
Cr-Commit-Position: refs/heads/master@{#33618}
Port 0637f5f64c
Original commit message:
If we deoptimize from TurboFan or Crankshaft into the body of a for-in
loop and that for-in mode then switches to slow mode (i.e. has to call
%ForInFilter), we have to record that feedback, because otherwise we
might actually OSR into that loop assuming that it's fast mode still,
or even worse recompile the function later when we call it again w/o
having rerun the for-in loop in fullcodegen from the beginning (where
was previously the only place we could learn).
R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:3650
LOG=n
Review URL: https://codereview.chromium.org/1644383002
Cr-Commit-Position: refs/heads/master@{#33617}
String wrappers (new String("foo")) are special objects: their string
characters are accessed like elements, and they also have an elements
backing store. This used to require a bunch of explicit checks like:
if (obj->IsJSValue() && JSValue::cast(obj)->value()->IsString()) {
/* Handle string characters */
}
// Handle regular elements (for string wrappers and other objects)
obj->GetElementsAccessor()->Whatever(...);
This CL introduces new ElementsKinds for string wrapper objects (one for
fast elements, one for dictionary elements), which allow folding the
special-casing into new StringWrapperElementsAccessors.
No observable change in behavior is intended.
Review URL: https://codereview.chromium.org/1612323003
Cr-Commit-Position: refs/heads/master@{#33616}
Previously, String.prototype.normalize constructed its ICU input
string as a null-terminated string. This creates a bug for strings
which contain a null byte, which is allowed in ECMAScript. This
patch constructs the ICU string based on its length so that the
entire string is normalized.
R=jshin@chromium.org
BUG=v8:4654
LOG=Y
Review URL: https://codereview.chromium.org/1645223003
Cr-Commit-Position: refs/heads/master@{#33614}
If we deoptimize from TurboFan or Crankshaft into the body of a for-in
loop and that for-in mode then switches to slow mode (i.e. has to call
%ForInFilter), we have to record that feedback, because otherwise we
might actually OSR into that loop assuming that it's fast mode still,
or even worse recompile the function later when we call it again w/o
having rerun the for-in loop in fullcodegen from the beginning (where
was previously the only place we could learn).
R=mstarzinger@chromium.org
BUG=v8:3650
LOG=n
Review URL: https://codereview.chromium.org/1638303008
Cr-Commit-Position: refs/heads/master@{#33612}
Port cb9b801069
Original commit message:
The previous versions of Math.max and Math.min made it difficult to
optimize those (that's why we already have custom code in Crankshaft),
and due to lack of ideas what to do about the variable number of
arguments, we will probably need to stick in special code in TurboFan
as well; so inlining those builtins is off the table, hence there's no
real advantage in having them around as "not quite JS" with extra work
necessary in the optimizing compilers to still make those builtins
somewhat fast in cases where we cannot inline them (also there's a
tricky deopt loop in Crankshaft related to Math.min and Math.max, but
that will be dealt with later).
So to sum up: Instead of trying to make Math.max and Math.min semi-fast
in the optimizing compilers with weird work-arounds support %_Arguments
%_ArgumentsLength, we do provide the optimal code as native builtins
instead and call it a day (which gives a nice performance boost on some
benchmarks).
BUG=
Review URL: https://codereview.chromium.org/1643973002
Cr-Commit-Position: refs/heads/master@{#33611}
Also remove duplicate code Disassemble, which is already done in TF pipeline.
BUG=
Review URL: https://codereview.chromium.org/1634653002
Cr-Commit-Position: refs/heads/master@{#33610}
The for-in slow mode implementation in Crankshaft unconditionally
deoptimizes when %ForInFilter returns undefined instead of just
skipping the item. Even worse, there's nothing we can learn from
that deopt, so we will eventually optimize again and hit exactly
the same problem again once we get back to optimized code.
R=mvstanton@chromium.org
BUG=v8:3650
LOG=n
Review URL: https://codereview.chromium.org/1647093002
Cr-Commit-Position: refs/heads/master@{#33609}
This refactors how the BytecodeArrayIterator is passed to visitation
methods on the BytecodeGraphBuilder. We no longer pass it explicitly,
but use the field accessor instead. Note that const-ness is still
preserved and visitation methods are still not able to mutate the
iterator. The main goal of this refactoring is increased readability.
R=rmcilroy@chromium.org
Review URL: https://codereview.chromium.org/1642893004
Cr-Commit-Position: refs/heads/master@{#33607}
