This is in preparation to the removal of the FullCodeGenerator, we no
longer need the ability to stress the underlying implementation.
R=rmcilroy@chromium.org
BUG=v8:6409
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Iad3177d6de4a68b57c12a770b6e85ed7a9710254
Reviewed-on: https://chromium-review.googlesource.com/584747
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47276}
Removes the --ignition flag which is now on by default. Adds a
--stress-fullcodegen flag which enables running all functions supported
by fullcodegen to be compiled by fullcodegen.
This will enable moving parser internalization later when we are not
stressing fullcodegen or compiling asm.js functions.
BUG=v8:5203, v8:6409, v8:6589
Change-Id: I7fa68016d4e734755434ec0b4e749ef65ffa7f4e
Reviewed-on: https://chromium-review.googlesource.com/565569
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46635}
By creating the boilerplate only on the second instantiation we cannot
propagate back the elements transitions early enough. The resulting literals
would change the initial ElementsKind one step too late and already pollute
ICs that went to monomorphic state.
- Disable lazy AllocationSites for literals containing arrays
- Introduce new ComplexLiteral class to share code between ObjectLiteral
and ArrayLiteral
- RegexpLiteral now no longer needs a depth_ field
Bug: v8:6517, v8:6519, v8:6211
Change-Id: Ia88d1878954e8895c3d00a7dda8d71e95bba005c
Reviewed-on: https://chromium-review.googlesource.com/563305
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46603}
This improves the general Array constructor call performance (w/o
usable AllocationSite feedback) in TurboFan by ~2x, i.e. for example
invoking the Array constructor like this
var a = Array.call(undefined, n);
instead of
var a = Array(n);
such that the CallIC doesn't know that it's eventually calling the
Array constructor.
It also thus changes the single argument Array constructor to always
return holey arrays. Previously the single argument case for the Array
constructor was somehow trying to dynamically detect 0 and in that case
returned a packed array instead of a holey one. That adds quite a lot
of churn, and doesn't seem to be very useful, especially since this
might lead to unnecessary feedback pollution later.
R=mvstanton@chromium.org
Bug: v8:2229, v8:5269, v8:6399
Change-Id: I3d7cb9bd975ec0e491e3cdbcf1230185cfd1e3de
Reviewed-on: https://chromium-review.googlesource.com/565721
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46538}
This mostly reverts commit c503b80595 but fixes
an issue where literals would always be pretenured on first instantiation.
As a cleanup we pass in a PretenureFlag instead of using the FeedbackVector as
indicator.
Bug: v8:6211
Change-Id: Id328552620e33f5083519bcba1e24396d162d516
Reviewed-on: https://chromium-review.googlesource.com/555670
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46342}
It might happen that we deprecate the map of previous sub-literals if we create
literals with the same map several times. This is usually the case for
configuration arrays.
Bug: chromium:734051
Change-Id: I82284e5aae632286135b2092816d776d229c65af
Reviewed-on: https://chromium-review.googlesource.com/538665
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46003}
With the introduction of the fast-cloning double fields in the CSA stub for
literals we forgot to check for deprecated maps. As a result every subsequent
IC-miss would have to migrate the objects from such boilerplates.
This CL makes sure we don't use the deprecated map when copying boilerplates,
thus restoring the original behavior.
Bug: v8:6211 chromium:728682
Change-Id: If9ea1e0c5c6fb4236cb7a82ea33306a600925ac3
Reviewed-on: https://chromium-review.googlesource.com/538677
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45981}
Storing the boilerplate on the first run leads to memory ovehead for code
that is run only once. Hence we directly return the creating literal on the
first run and only start creating copies from the second run on.
Bug: v8:6211
Change-Id: I69b96d124a5b594b991fdbcc76dbf935d973ffad
Reviewed-on: https://chromium-review.googlesource.com/530688
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45975}
This CL changes certain frequently-called Array builtins to use CodeStubArguments
rather than peek at the stack frames above array builtins to determine if options
arguments have been passed into them.
Previous failure likely due to unfortunate/unluckily timed GC that moved due to
changed timing/allocation from this CL. Test mitigation for allocation-site-info.js
included.
BUG=v8:1956
LOG=N
Review-Url: https://codereview.chromium.org/2829093004
Cr-Commit-Position: refs/heads/master@{#44998}
1. Replaces --crankshaft with --opt in tests.
2. Also fixes presubmit to check for --opt flag when
assertOptimized is used.
3. Updates testrunner/local/variants.py and
v8_foozie.py to use --opt flag.
This would mean, nooptimize variant means there are
no optimizations. Not even with %OptimizeFunctionOnNextCall.
Bug:v8:6325
Change-Id: I638e743d0773a6729c6b9749e2ca1e2537f12ce6
Reviewed-on: https://chromium-review.googlesource.com/490206
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44985}
This CL adds --crankshaft and --no-always-opt flags to the tests that use
assertOptimized() and assertUnoptimized() respectively.
This CL also adds presubmit checks that ensure that tests have the proper
flags set.
BUG=v8:5890
Review-Url: https://codereview.chromium.org/2653753007
Cr-Commit-Position: refs/heads/master@{#42709}
The way desugared instanceof called OrdinaryHasInstance if the lookup of
@@hasInstance failed was incorrect.
BUG=v8:4774
LOG=N
Review URL: https://codereview.chromium.org/1812793002
Cr-Commit-Position: refs/heads/master@{#34855}
When FLAG_pretenure_call_new is on, we emit mementos on new object creation
in full code, and consume the feedback in crankshaft. A key difference in the
generated code for stubs is the allocation of an additional type vector slot for the
CallNew AST node, which simplifies the CallConstructStub and CallFunctionStub
considerably.
Some performance tuning still needs to be addressed, therefore the flag is off at
this moment, though fully functional. The goal is to remove the flag as soon as
possible, which allows much code deletion (yay).
R=hpayer@chromium.org
Review URL: https://codereview.chromium.org/132963012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20076 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Our generic KeyedStoreIC doesn't handle the case when a callback is
set on array elements in the prototype chain of the object, nor do
we recognize that we need to avoid the monomorphic case if these
callbacks exist.
This CL addresses the issue by looking for dictionary elements in
the prototype chain on IC misses and crankshaft element store
instructions. When found, the generic IC is used. The generic IC is
changed to go to the runtime in this case too.
In general, keyed loads are immune from this problem because they
won't return the hole: discovery of the hole goes to the runtime where
the callback will be found in the prototype chain. Double array loads
in crankshaft can return the hole but only if the prototype chain is
unaltered (we will catch such alterations).
Includes the following patch as well (already reviewed by bmeurer):
Performance regression found in test regress-2185-2.js. The problem was
that the bailout method for TransitionAndStoreStub was not performing
the appropriate transition.
(Review URL for the ElementsTransitionAndStoreIC_Miss change:
https://codereview.chromium.org/26911007)
R=danno@chromium.org
Review URL: https://codereview.chromium.org/35413006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17525 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
They make assumptions about elementskind of arrays based on allocation site
feedback. This feedback is highly dependent on mementos, unrooted objects
placed behind arrays in the heap meant to live until the next scavenge.
GcStress does many more gcs than normal, and wrecks havoc with this kind
of test.
BUG=
R=hpayer@chromium.org
Review URL: https://codereview.chromium.org/23449042
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16832 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
properly when it is called with a function pointer in the type cell,
instead assuming that an AllocationSite object should be present. The
case where this can happen is if the cell is uninitialized, then the
first constructor call made is to the Array function of a different
context. In that case, we'll store the function pointer in the cell,
and then go ahead and call the array constructor stub too. The bug is
fixed by checking for the AllocationSite object map. If not found, the
constructor stub goes forward with a default ElementsKind, just as in
several other cases.
A test in allocation-site-info.js was beefed up to make sure the state
chain described above is traversed.
BUG=
R=hpayer@chromium.org, hpayer@google.com
Review URL: https://codereview.chromium.org/18277006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15555 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* Cleanup of LCallNewArray::PrintDataTo() method
* Created HCallNewArray::PrintDataTo()
* Created many more tests in array-constructor-feedback.js
* Removed redundant instructions in
GenerateRecordCallTarget
* Bugfix in CreateArrayDispatchOneArgument: on a call to
new Array(0), we'd like to set the type feedback cell to
a packed elements kind, but we shouldn't do it if the
cell contains the megamorphic sentinel.
* When used from crankshaft, ArrayConstructorStubs can
avoid verifying that the function being called is the
array function from the current native context, relying
instead on the fact that crankshaft issues an
HCheckFunction to protect the constructor call. (this
new minor key is used in LCodeGen::DoCallNewArray(), and
influences code generation in
CodeStubGraphBuilderBase::BuildArrayConstructor()).
* Optimization: the array constructor specialized for
FAST_SMI_ELEMENTS can save some instructions by looking
up the correct map on the passed in constructor, rather
than indexing into the array of cached maps per element
kind.
BUG=
R=danno@chromium.org
Review URL: https://codereview.chromium.org/17091002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15383 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
If the runtime is taken for a constructor like "new Array(100000)", where
allocation site info already led to an elements kind of DOUBLE, then the runtime
would fail to transition the array to dictionary mode. Better to recognize this
case and avoid wasting time by following the advice. Furthermore, it offers a
way to recognize that the array should be in dictionary mode (though a future
checkin will capitalize on that).
BUG=
R=danno@chromium.org
Review URL: https://codereview.chromium.org/15993012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14966 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
