Initial step towards separating IC (map check(s)), handler frontend
(prototype-check) and handler backend (actual handler code).
- Still need to split the map-check (IC) from rest of the prototype
chain check.
- Still need to turn different parts in own code objects and cache them
in more optimal places.
Review URL: https://chromiumcodereview.appspot.com/12207016
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13604 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r13533 (2f339757)
Original commit message:
In preparation of supporting stubs that deopt and then need to push their
register-based parameters to an arguments area on the stack that gets properly
collected, add StubFailureTrampolineFrames to hold those parameters.
BUG=
TEST=
Review URL: https://codereview.chromium.org/12087053
Patch from Akos Palfi <palfia@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13560 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r13475 (0076e1ee)
Original commit message:
With parallel recompilation enabled, objects made accessible by handles may
have changed between graph construction and graph optimization. Therefore
we must not assume that information on those objects remain the same between
those two phases. To police this, we forbid handle dereferencing during
graph optimization.
Exceptions to this rule are:
- Dereferencing the handle to obtain the raw location of the object. This
is safe since parallel recompilation acquires RelocationLock
- Some places that dereference the handle for a type check. These are checked
to be safe on a case-by-case basis.
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/12049037
Patch from Akos Palfi <palfia@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13477 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r13454 (2c0dd0ff)
Original commit message:
HCheckPrototypeMaps currently records the prototype and the holder of the
prototype chain (both ends of the chain) and assumes that the chain elements
and their maps did not change in during the entirety of Crankshaft. The actual
traversal of the prototype chain happens in Lithium at code generation.
With parallel compilation, this assumption is not longer correct.
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/12036030
Patch from Akos Palfi <palfia@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13476 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r13462 (74f0ddf6)
Original commit message:
Incorrect ARM assembly in MacroAssembler::TestJSArrayForAllocationSiteInfo Restored test code in allocation-site-info.js that was failing on ARM because of this bug.
BUG=
TEST=
Review URL: https://codereview.chromium.org/11896037
Patch from Akos Palfi <palfia@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13465 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r13341 (673c3243)
Original commit message:
The basic idea is to tag OOM-Failure objects with an ID indicating where they were created. This requires changes to equality comparisons.
BUG=
TEST=
Review URL: https://codereview.chromium.org/11972002
Patch from Akos Palfi <palfia@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13395 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r13330 (6d9ce8a8)
Original commit message:
Adapt Danno's Track Allocation Info idea to fast literals. When allocating a literal array, we store an AllocationSiteInfo object right after the JSArray, with a pointer to the boilerplate object. Later, if the array transitions we check for the continued existence of the temporary AllocationSiteInfo object (has no roots). If found, we'll use it to transition the boilerplate array as well.
Danno's original changeset: https://codereview.chromium.org/10615002/
BUG=
TEST=
Review URL: https://codereview.chromium.org/11783048
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13339 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r13320 (916d70a6)
Original commit message:
Remove code specific to KeyedLoadICs in DoCompiledStubFrame on all platforms, driving stub frame translation by the register parameter information found in a stub's CodeStubInterfaceDescriptor.
BUG=
TEST=
Review URL: https://codereview.chromium.org/11783046
Patch from Akos Palfi <palfia@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13336 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r13288 (5fa2c889)
Original commit message:
This change associates TypeFeedbackIds with ToBoolean stubs in
full-compiled code on ARM, allowing their information to be used in
Crankshaft. This eliminates unnecessary checks, especially in
DoBranch.
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/11801003
Patch from Akos Palfi <palfia@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13315 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
There are now NONE and NONE64 RelocInfo types, but only ARM uses them
both at the same time. They were added in:
https://chromiumcodereview.appspot.com/11191029/
I'll rename NONE to NONE32 in a later CL.
This CL cleans up the RelocInfo::NONE usage by:
- Using RelocInfo::IsNone when testing for NONE-ness.
- Using NONE on 32-bit platforms (MIPS and IA32), and NONE64 on 64-bit
platforms (x64).
This cleans up the code and prevents it from evolving bugs in the future
because NONE32 and NONE64 are used in misleading ways.
R= ulan@chromium.org
Review URL: https://chromiumcodereview.appspot.com/11695006
Patch from JF Bastien <jfb@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13307 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
