There's actually no need to have the transition as part of the HStoreNamedField instruction. In fact, it is cleaner and faster to generate a separate HStoreNamedField for the transition map. This will also help to eliminate map stores with store elimination, as well as reduce register pressure for transitioning stores on ia32.
R=hpayer@chromium.org
Review URL: https://codereview.chromium.org/295743002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21383 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
by escape analysis). Added several tests that expose the bug.
Summary:
LCodegen::AddToTranslation assumes that Lithium environments are
generated by depth-first traversal, but LChunkBuilder::CreateEnvironment
was generating them in breadth-first fashion. This fixes the
CreateEnvironment to traverse the captured objects depth-first.
Note:
It might be worth considering representing LEnvironment by a list
with the same order as the serialized translation representation
rather than having two lists with a subtle relationship between
them (and then serialize in a slightly different order again).
R=titzer@chromium.org, mstarzinger@chromium.org
LOG=N
BUG=
Review URL: https://codereview.chromium.org/93803003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18470 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In the process:
- Add a command-line flag --opt-code-positions to track source position information throughout optimized code.
- Add a subclass of the hydrogen graph builder to ensure that the source position is properly set on the graph builder for all generated hydrogen code.
- Overhaul handling of source positions in hydrogen to ensure they are passed through to generated code consistently and in most cases transparently.
Originally reviewed in this CL: https://codereview.chromium.org/24957003/
Review URL: https://codereview.chromium.org/29123008
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17295 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Use V8_FINAL and V8_OVERRIDE in Ast classes.
- Use V8_FINAL and V8_OVERRIDE in Lithium mips backend.
- Use V8_FINAL and V8_OVERRIDE in Lithium arm backend.
- Use V8_FINAL and V8_OVERRIDE in Lithium x64 backend.
- Use V8_FINAL and V8_OVERRIDE in Lithium ia32 backend.
- Use V8_FINAL and V8_OVERRIDE in Lithium classes.
- Use V8_FINAL and V8_OVERRIDE in Hydrogen classes.
TBR=dslomov@chromium.org
Review URL: https://codereview.chromium.org/22796020
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16244 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Use V8_FINAL and V8_OVERRIDE in objects.
- Use V8_FINAL and V8_OVERRIDE in Ast classes.
- Use V8_FINAL and V8_OVERRIDE in Lithium mips backend.
- Use V8_FINAL and V8_OVERRIDE in Lithium arm backend.
- Use V8_FINAL and V8_OVERRIDE in Lithium x64 backend.
- Use V8_FINAL and V8_OVERRIDE in Lithium ia32 backend.
- Use V8_FINAL and V8_OVERRIDE in Lithium classes.
- Use V8_FINAL and V8_OVERRIDE in Hydrogen classes.
R=dslomov@chromium.org
Review URL: https://codereview.chromium.org/23064017
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16232 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change implements a simple data-flow analysis pass over captured
objects to the existing escape analysis. It tracks the state of values
in the Hydrogen graph through CapturedObject marker instructions that
are used to construct an appropriate translation for the deoptimizer to
be able to materialize these objects again.
This can be considered a combination of scalar replacement of loads and
stores on captured objects and sinking of unused allocations.
R=titzer@chromium.org
TEST=mjsunit/compiler/escape-analysis
Review URL: https://codereview.chromium.org/21055011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16098 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This allows the deoptimizer to materialize objects (e.g. the arguments
object) while deopting without having a consective stack area holding
the object values. The LEnvironment explicitly tracks locations for
these values and preserves them in the translation.
R=svenpanne@chromium.org
TEST=mjsunit/compiler/inline-arguments
Review URL: https://codereview.chromium.org/16779004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15087 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This includes:
* Adding support for saving callee-clobbered double registers in Crankshaft code.
* Adding a new "HTrapAllocationMemento" hydrogen instruction to handle AllocationSiteInfo data in crankshafted stubs.
* Adding a new "HAllocate" hydrogen instruction that can allocate raw memory from the GC in crankshafted code.
* Support for manipulation of the hole in HChange instructions for Crankshafted stubs.
* Utility routines to manually build loops and if statements containing hydrogen code.
Review URL: https://codereview.chromium.org/11659022
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13585 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This fixes materialization of arguments objects for strict mode functions during
deoptimization. We materialize arguments from the stack area where optimized
code pushes the arguments when entering the inlined environment. For adapted
invocations we use the arguments adaptor frame for materialization.
R=svenpanne@chromium.org
BUG=v8:2261
TEST=mjsunit/regress/regress-2261,mjsunit/compiler/inline-arguments
Review URL: https://chromiumcodereview.appspot.com/10908194
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12489 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Safe operations are those that either do not observe unsignedness or have special support for uint32 values:
- all binary bitwise operations: they perform ToInt32 on inputs;
- >> and << shifts: they perform ToInt32 on left hand side and ToUint32 on right hand side;
- >>> shift: it performs ToUint32 on both inputs;
- stores to integer external arrays (not pixel, float or double ones): these stores are "bitwise";
- HChange: special support added for conversions of uint32 values to double and tagged values;
- HSimulate: special support added for deoptimization with uint32 values in registers and stack slots;
- HPhi: phis that have only safe uses and only uint32 operands are uint32 themselves.
BUG=v8:2097
TEST=test/mjsunit/compiler/uint32.js
Review URL: https://chromiumcodereview.appspot.com/10778029
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12367 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
