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
- The global object has a reference to the current global scope chain.
Running a script adds to the chain if it contains global lexical declarations.
- Scripts are executed relative to a global, not a native context.
- Harmony let and const bindings are allocated to the innermost global context;
var and function still live on the global object.
(Lexical bindings are not reflected on the global object at all,
but that will probably change later using accessors, as for modules.)
- Compilation of scripts now needs a (global) context (previously only eval did).
- The global scope chain represents one logical scope, so collision tests take
the chain into account.
R=svenpanne@chromium.org
BUG=
Review URL: https://chromiumcodereview.appspot.com/10872084
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12398 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
The underlying problem is that for compound/count operations we use the *load*
type feedback for storing, too. For normal properties this doesn't matter, but
for accessor properties we should better use the *store* type feedback, which
would be available, too. This consistent feedback usage could be guaranteed if
we removed the heavy copy-n-paste in the crankshaft code generation for
compound/count operations and assignments/property loads.
To be on the safe side, we postpone this refactoring and do a quick and easily
mergeable fix.
BUG=140083
TEST=mjsunit/regress/regress-crbug-140083.js
Review URL: https://chromiumcodereview.appspot.com/10828146
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12252 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
