The current usage of this runtime function is broken as it does not
prevent inlining of the affected function but rather bails out from the
whole unit of compilation after trying to inline affected functions.
This simplifies said runtime function to avoid accidental misuse.
R=titzer@chromium.org
TEST=mjsunit/never-optimize
Review URL: https://codereview.chromium.org/19776006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15762 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
To fix the issue at hand regarding constant function calls and perhaps
other hidden issues regarding negative lookups, we basically add a
"marker instruction", just for harvesting purposes. Our type feedback
oracle is really, really fragile, we should better switch to some more
explicit and robust scheme soon.
BUG=chromium:252797
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/19588002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15741 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Fix the invalid array length check, replacing it with a check of
the elements pointer similar to TransitionElementsKindStub.
Refactor common code from ElementsTransitionAndStoreStub and TransitionElementsKindStub into BuildTransitionElementsKind() helper method.
Add test case for the MD5 computation that used to crash before,
and a small test case for the specific issue.
R=danno@chromium.org
Review URL: https://codereview.chromium.org/19367003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15713 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The stub used to check the length of the JS array to see if
there's a need to duplicate the elements backing store. This
way it will not duplicate the elements array when going from
double to object even if the elements array is not the empty
fixed array. Later on it will then store pointers into a
FixedDoubleArray.
The native code stub used to check whether elements points to
the empty_fixed_array singleton instead of testing the length.
The Hydrogen stub does that as well now.
R=danno@chromium.org
Review URL: https://codereview.chromium.org/19289009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15701 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Further refinement to semantics that I have missed in previous change.
Both Blink and Firefox are permissive with arguments to .set method.
However, when first argument to "set" is a number, all implementations
throw, so that users know that
a.set(0,27)
does not assign 27 to 0th element of a, not 0 to 27th element of a.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/19210002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15684 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The code previously assumed that an array with fast properties must have
a writable length property. But Object.freeze() now exposes a way to make
length read-only without moving the object into slow mode. This patch
simply adds a !is_frozen check to the IC code. Any future optimizations
to attribute-setting on JSArrays will need to make similar accomodations.
R=danno
BUG=v8:2711,259548
Review URL: https://chromiumcodereview.appspot.com/19115002
Patch from Adam Klein <adamk@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15651 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
Their values are not used neither by the tick processor nor by CpuProfiler so it is just a waste of space.
TickSample used to be a transport for grabbed register values to TickSample::Trace, now they are passed in a special structure RegisterState which is allocated on the stack for the sampling period.
Some common pieces were moved from platform-dependent code into Sampler::SampleStack and TickSample::Init.
BUG=None
R=jkummerow@chromium.org, loislo@chromium.org
Review URL: https://codereview.chromium.org/18620002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15484 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
