Port r15087 (63e1626)
Original commit message:
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.
TEST=mjsunit/compiler/inline-arguments
BUG=
Review URL: https://codereview.chromium.org/16846002
Patch from Balazs Kilvady <kilvadyb@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15097 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r15079 (1ebdfdc6)
Original commit message:
When a generator suspends, it saves its state out to the heap and
unwinds try handlers but doesn't pop anything off the stack. Instead it
relies on no GC happening between the suspend and the return from the
generator. However this was not the case: boxing the result object
could cause GC, which would try to traverse the stack but would
misinterpret words from unwound try handlers as heap objects.
This CL changes to allocate the result objects before the suspend. It
also removes the generators-iteration skip introduced in r15065.
BUG=
Review URL: https://codereview.chromium.org/16820004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15096 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 current specification has GeneratorFunction() be like Function(),
except that it makes generator instances. This commit implements that
behavior. It also fills in a piece of the implementation where
otherwise calling GeneratorFunction or GeneratorFunctionPrototype would
cause an abort because they have no code.
R=mstarzinger@chromium.org
TEST=mjsunit/harmony/generators-iteration
TEST=mjsunit/harmony/generators-runtime
BUG=v8:2355,v8:2680
Review URL: https://codereview.chromium.org/15218004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15084 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When a generator suspends, it saves its state out to the heap and
unwinds try handlers but doesn't pop anything off the stack. Instead it
relies on no GC happening between the suspend and the return from the
generator. However this was not the case: boxing the result object
could cause GC, which would try to traverse the stack but would
misinterpret words from unwound try handlers as heap objects.
This CL changes to allocate the result objects before the suspend. It
also removes the generators-iteration skip introduced in r15065.
R=mstarzinger@chromium.org
TEST=mjsunit/harmony/generators-iteration
BUG=
Review URL: https://codereview.chromium.org/16801006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15079 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r15060 (8cdd204)
Original commit message:
- set "can be minus zero" flag properly so minus-zero checks are skipped
- skip "integer result?" check in division code when uses are truncating
- drive-by cleanup: consolidated computation of kCanOverflow flag for Add/Sub into range inference phase
BUG=v8:2132
R=plind44@gmail.com
Review URL: https://codereview.chromium.org/16645007
Patch from Balazs Kilvady <kilvadyb@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15070 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r15028 (258a047)
Original commit message:
Update the generators implementation to make "next" also do the job of
what was previously called "send" by taking an optional argument.
Remove send, and do a bunch of renamings.
BUG=v8:2355, v8:2715
Review URL: https://codereview.chromium.org/16735005
Patch from Balazs Kilvady <kilvadyb@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15049 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r15027 (3ffb343)
Original commit message:
The comments in ic-arm.cc::LoadIC indicated that the receiver should be
both in a register and on the stack. This isn't true in fact: the code
is careful to spill the receiver if needed.
This CL also fixes up a mistaken use of this convention in VisitYield.
BUG=
Review URL: https://codereview.chromium.org/16131004
Patch from Balazs Kilvady <kilvadyb@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15048 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Depending on what we know about the right operand, we basically do 3
different things (and the code is actually structured this way):
* If we statically know that the right operand is a power of 2, we do
some bit fiddling instead of doing a "real" modulus calculation.
This should actually be done on the Hydrogen level, not on the
Lithium level, but this will be a separate CL.
* If type feedback tells us that the right operand is a power of 2, we
do the same as above, but guarded by conditional deoptimization to
make sure that the assumption is still valid. In the long run, we
should make this guard visible on the Hydrogen level to make it
visible for GVN and other optimizations.
* In the general case we only do the minimum steps necessary and don't
try to be too clever, because cleverness actually slows us down on
real-world code.
If we look at the code gerators for LModI, we actually see that we
basically have 3 (4 on ARM) fundamentally different translations. I
don't really like lumping them together, they should probably be
different Lithium instructions. For the time being, I restructured the
generators to make this crystal-clear, at the cost of some duplication
regarding the power-of-2 cases. This will go away when we do the
strength reduction on the Hydrogen level, so I'd like to keep it as it
is for now.
Note that the MIPS part was only slightly restructured, there is still
some work to do there.
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/15769010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15034 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
