A reference to the caches array was embedded directly into the builtin
code and this allowed sharing objects between contexts.
Unfortunately, clearing the cache on GC won't prevent sharing so we
either have to have per-context builtin code or load the cache
indirectly from the current context. This change implements the second
approach. The first approach may be interesting to consider in the
future for some perfomance critical functions, and the current
approach can still be improved by putting the caches directly into the
global context (or even global objects).
Review URL: http://codereview.chromium.org/1731002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4486 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
(Fixed handling of out-of-bounds keys.)
String keyed load used to call STRING_CHAR_AT builtin that performs
two steps (get a char code, construct a one-char string from the
code), both of which have fast cases implemented as inline runtime
functions. In this chage most of the code from these functions is
extracted to a set of common generator functions in StringStubBase and
the fast cases are grouped together in the IC code.
Review URL: http://codereview.chromium.org/1582041
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4450 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
String keyed load used to call STRING_CHAR_AT builtin that performs
two steps (get a char code, construct a one-char string from the
code), both of which have fast cases implemented as inline runtime
functions. In this chage most of the code from these functions is
extracted to a set of common generator functions in StringStubBase and
the fast cases are grouped together in the IC code.
Review URL: http://codereview.chromium.org/1539039
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4444 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In the CEntryStub keep track of the actual skew from the correct alignment to ensure proper alignment before calling the runtime. Add checks to test the expected skew when running on hardware.
Use the PrepareCallCFunction/CallCFunction in a few other places.
Add check to the ARM simulator for correct alignment.
Add option --sim-stack-alignment to set the stack alignment in the simulator. Currntly only values 4 and 8 makes sense. 8 is the default to make snapshots generated with the simulator work on hardware requiring 8 byte stack alignment.
Review URL: http://codereview.chromium.org/1530043
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4425 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This re-applies r4220 and r4233, which was reverted in r4254 due to a bug. This bug has now been fixed, with the only change being line 2884 changed from
__ SmiTag(left_side->reg());
to
__ SmiTag(operand->reg());
Added a regression test.
BUG=http://crbug.com/39160
TEST=test/mjsunit/regress/regress-crbug-39160.js
Review URL: http://codereview.chromium.org/1251009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4261 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Instead of testing the value of a constant frame element to determine
the type we compute its type information at construction time.
This speeds up querying the type information during code generation.
This change also adds support for Integer32 constants and sets
the type information accordingly.
Review URL: http://codereview.chromium.org/1277001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4256 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Previously we marked compare operations that occurred as for loop
conditions so as to avoid inlining the floating-point code for them.
Begin marking all expressions that occur as any loop condition
(because they are never dead code).
Review URL: http://codereview.chromium.org/1074009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4227 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Inline floating point compare instead of calling the stub when the following conditions are met:
* Code is in a loop
* Compare is not a for loop condition
* Compare is not an equal comparison
This inlined code handles heap number to heap number and heap number to smi compare. It can also handle smi to smi compare, but whenever there is a chance of comparing two smis the smi compare is inlined before the inlined floating point compare. Support for non SSE2 hardware is included.
A new set of variants of the compare stub without the floating point comparison code is called if the inline comapre fails due to the operands not beeing heap numbers or smis.
The virtual frame has been extended with a branch taking two live results to be carried through to the destination. This makes this change much simpler as the inlined code have two live results in registers and a number of bailouts.
CompareStub::GetName needs to be updated as well. I will do that as a separate change.
Also inlined equality check if both operands can't be NaN. This can only provide positive equals if it is the same object.
Review URL: http://codereview.chromium.org/1117011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4220 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
