code. By the time we optimize the code, we'll be able to decide on new or old
space based on the number of surviving objects after one or more gcs.
The mechanism is a "memento" placed behind objects in the heap. It's currently
done for array and object literals, with plans to use mementos for constructed
objects as well (in a later CL).
The feature is behind the flag allocation_site_pretenuring, currently off.
R=hpayer@chromium.org
Review URL: https://codereview.chromium.org/40063002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18104 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
For 31-bit smis, we don't need to explicitly check whether the
combined string length exceeds the max supported string length,
since the value must be converted to a smi at some point (i.e.
when it is stored into the string length field of the resulting
string), which will emit an overflow check.
For 32-bit smis, we insert an explicit check that the combined
string length does not exceed String::kMaxLength.
This also enables to get rid of the JoinContinuation() usage in
BuildUncheckedStringAdd().
BUG=v8:2990
LOG=n
R=mvstanton@chromium.org
Review URL: https://codereview.chromium.org/82733003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18005 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This removes tons of architecture-specific code and makes it easy to
experiment with other pseudo-RNG algorithms. The crankshafted code is
extremely good, keeping all things unboxed and doing only minimal
checks, so it is basically equivalent to the handwritten code.
When benchmarks are run without parallel recompilation, we get a few
percent regression on SunSpider's string-validate-input and
string-base64, but these benchmarks run so fast that the overall
SunSpider score is hardly affected and within the usual jitter. Note
that these benchmarks actually run even faster when we don't
crankshaft at all on the main thread (the regression is not caused by
bad code, it is caused by Crankshaft needing a few hundred microsecond
for compilation of a trivial function). Luckily, when parallel
recompilation is enabled, i.e. in the browser, we see no regression at
all!
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/68723002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17955 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The %_OneByteSeqStringSetChar intrinsic expects its arguments to be checked before being called for efficiency reasons, but the fuzzer provided no such checks. Now the intrinsic is robust to bad input if FLAG_debug_code is set.
R=yangguo@chromium.org
TEST=test/mjsunit/regress/regress-320948.js
BUG=chromium:320948
LOG=Y
Review URL: https://codereview.chromium.org/72813004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17886 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Add static_cast<int> in HPositionInfo::position to please Win64 build.
Improvements in positions handling in optimizing compiler.
- When building binary arithmetic op and comparison restore source position of the operation itself before building operation itself after it was changed by building operands. This ensures that position recorded for operation points to the operation token instead of pointing to the rightmost operand;
- Add support for recording operands' positions and use these positions when inserting HChange instructions;
- When generating hydrogen.cfg emit H-instruction position as BCI (previously 0 was emitted), additionally on every lithium instruction emit annotation pointing to corresponding hydrogen-instruction. This allows to easily reach from deopt_id to lithium instruction and from it to hydrogen instruction and source position.
R=danno@chromium.org
Review URL: https://codereview.chromium.org/59703011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17848 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- When building binary arithmetic op and comparison restore source position of the operation itself before building operation itself after it was changed by building operands. This ensures that position recorded for operation points to the operation token instead of pointing to the rightmost operand;
- Add support for recording operands' positions and use these positions when inserting HChange instructions;
- When generating hydrogen.cfg emit H-instruction position as BCI (previously 0 was emitted), additionally on every lithium instruction emit annotation pointing to corresponding hydrogen-instruction. This allows to easily reach from deopt_id to lithium instruction and from it to hydrogen instruction and source position.
BUG=
R=danno@chromium.org
Review URL: https://codereview.chromium.org/49203002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17765 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
patch from issue 54583003 (dependent code).
Zero arguments - very easy
1 argument - three special cases:
a) If length is a constant in valid array length range,
no need to check it at runtime.
b) respect DoNotInline feedback on the AllocationSite for
cases that the argument is not a smi or is an integer
with a length that should create a dictionary.
c) if kind feedback is non-holey, and length is non-constant,
we'd have to generate a lot of code to be correct.
Don't inline this case.
N arguments - one special case:
a) If a deopt ever occurs because an input argument isn't
compatible with the elements kind, then set the
DoNotInline flag.
BUG=
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/55933002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17741 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Lithium uses indexes after the maximium value ID in the HGraph as indexes
of virtual registers and assumes that the maximum value ID does not change.
The IsStandardConstant and GetConstantXX functions could add constants to
HGraph, which aliased virtual registers with real values. This could confuse
the register allocator to think that a value in a virtual register is tagged
and to incorrectly set it in the pointer map.
BUG=298269
TEST=mjsunit/regress/regress-298269.js
R=verwaest@chromium.org
Review URL: https://chromiumcodereview.appspot.com/66693002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17599 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
