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
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
The predicate CanBeSpilled had a bug, prohibiting the necessary spilling and
correct splitting of live ranges. Removed a redundant assertion immediately done
by the callee anyway.
Thanks to Slava for help with that issue and the entertaining historical
background of the whole story... ;-)
BUG=177883
Review URL: https://codereview.chromium.org/12631012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13891 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This allows Crankshaft to completely inline a f.apply() dispatch if the
exact number of arguments is known and the function is constant. The
deoptimizer doesn't generate the f.apply() frame during deoptimization,
so the materialized frames look like f.apply() did a tailcall.
R=jkummerow@chromium.org
TEST=mjsunit/compiler/inline-function-apply
Review URL: https://codereview.chromium.org/12263004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13665 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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.
R=mstarzinger@chromium.org
BUG=
Review URL: https://chromiumcodereview.appspot.com/11864013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13454 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Previously Crankshaft emitted a generic load for these, now we emit a load of a
named field, guarded by a proto chain check.
LCheckPrototypeMaps now returns the holder, which is for free, because it
already had to check its map as the last step, anyway. This is in sync with what
StubCompiler::CheckPrototype does.
Review URL: https://codereview.chromium.org/11338030
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12847 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
xmm0 is not saved across runtime call on x64 because MacroAssembler::EnterExitFrameEpilogue preserves only allocatable XMM registers unlike on ia32 where it preserves all registers.
Cleanup handling of shifts: SHR can deoptimize only when its a shift by 0, all other shift never deoptimize.
Fix type inference for i-to-t change instruction. On X64 this ensures that write-barrier is generated correctly.
R=danno@chromium.org
Review URL: https://chromiumcodereview.appspot.com/10868032
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12373 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
Highlights of this CL:
* Introduced a new opcode in the deoptimizer for a setter stub frame.
* Added a global setter stub for returning after deoptimizing a setter.
* We do not need special deopt support for getters, although the getter stub creates an internal frame. The normal machinery works just right for this case, although we generate a stack that can never occur during normal fullcode execution. If this hurts us one day, we can parameterize and reuse the setter deopt machinery.
Review URL: https://chromiumcodereview.appspot.com/10855098
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12328 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Currently we inline functions with different contexts only on ia32, so we have
to move the helper functions for the various contexts to the top level. Further
more, "new Object()" seems to prevent inlining, too, so we us a simple object
literal.
Although things get consistently inlined now, something strange seems to happen
in test/effect contexts: The DEOPT output seems to contain too few frames, and
we don't get any DEOPT ouput after the first time for those contexts. This has
to be investigated...
TBR=mstarzinger@chromium.org
Review URL: https://chromiumcodereview.appspot.com/10836258
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12312 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Currently only simple setter calls are handled (i.e. no calls in count
operations or compound assignments), and deoptimization in the setter is not
handled at all. Because of the latter, we temporarily hide this feature behind
the --inline-accessors flag, just like inlining getters.
We now use an enum everywhere we depend on the handling of a return value,
passing around several boolean would be more confusing.
Made VisitReturnStatement and the final parts of TryInline more similar, so
matching them visually is a bit easier now.
Simplified the signature of AddLeaveInlined, the target of the HGoto can simply
be retrieved from the function state.
Review URL: https://chromiumcodereview.appspot.com/10836133
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12286 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
