As the start index is already passed it is easy to calculate the "at start" boolean in generated code. Also as direct entry has been implemented this needs to be done in generated code anyway, and therefore might as well be moved to the generated code for RegExp. The "at start" value is now calcualted as a local variable on the native RegExp frame based on the value of the start index argument.

The x64 version have been tested on both Linux and 64-bit Windows Vista.

For ARM I have tested cctest/test-regexp on ARM hardware, but the rest of the tests have only been run on the ARM simulator.
Review URL: http://codereview.chromium.org/554078

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3709 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

1. MUL and DIV on SMIs.
2. When calling GenericBinaryOpStub from a virtual frame.
3. When generating code for a loop counter.
Overall performance gain is about 0.6%.
Review URL: http://codereview.chromium.org/555098

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3708 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Review URL: http://codereview.chromium.org/556018

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3705 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Review URL: http://codereview.chromium.org/549147

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3703 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Review URL: http://codereview.chromium.org/546147

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3700 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This reduces chances of improper usage, see http://code.google.com/p/v8/issues/detail?id=586
for more details.

BUG=586

Review URL: http://codereview.chromium.org/555072

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3696 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

See Kevin's comments for http://codereview.chromium.org/554062.
Review URL: http://codereview.chromium.org/543193

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3695 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Also fixing some formatting issues.
Review URL: http://codereview.chromium.org/556002

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3694 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Review URL: http://codereview.chromium.org/545125


git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3693 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Currently arguments are never passed on registers (due to the way ArgsInRegistersSupported is written) and
if they were, the stub would break in several places because registers are not preserved properly in the
course of execution. This CL makes use of registers more often (than never) and makes sure that registers are
handler properly.
A peformance gain is small (0.2-0.3%) but stable.
This CL was extracted from the one sent out earlier (http://codereview.chromium.org/551093).

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3692 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Review URL: http://codereview.chromium.org/543187

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3691 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

See Chromium bug 32637.

Review URL: http://codereview.chromium.org/553067

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3689 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Patch by Erich Ocean and Ryan Dahl.

Review URL: http://codereview.chromium.org/545125

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3688 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Review URL: http://codereview.chromium.org/545155

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3687 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Review URL: http://codereview.chromium.org/555049

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3683 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

2.1.0. This means that the next version pushed to trunk will
be the first version in the 2.1.x series. 
Review URL: http://codereview.chromium.org/551139

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3682 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

We now test for a smi before calling ToNumber and inline
the smi increment/decrement for ++ and --. There only a small
increase in code size but loops in top-level code are
becoming much faster as a result.

Review URL: http://codereview.chromium.org/553056

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3681 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

BUG=589,27967.

Review URL: http://codereview.chromium.org/555048

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3680 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

As an afterthought, I realized that I put function objects moves
reporting into a method that deals with only code object moves.  I've
looked up that function objects are allocated in old pointer space and
new space, so I moved logging to the corresponding VM methods.

BUG=553

Review URL: http://codereview.chromium.org/552089

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3679 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

The stub for calling RegExp directly now also handles two byte strings.

Support for flat cons strings added for both ascii and two byte.

Some code code simplifications and added a few constants.
Review URL: http://codereview.chromium.org/545151

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3678 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Review URL: http://codereview.chromium.org/543154

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3676 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Review URL: http://codereview.chromium.org/552068

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3675 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Review URL: http://codereview.chromium.org/552043

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3674 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

The problem appeared due to a fact that stubs doesn't create a stack
frame, reusing the stack frame of the caller function. When building
stack traces, the current function is retrieved from PC, and its
callees are retrieved by traversing the stack backwards. Thus, for
stubs, the stub itself was discovered via PC, and then stub's caller's
caller was retrieved from stack.

To fix this problem, a pointer to JSFunction object is now captured
from the topmost stack frame, and is saved into stack trace log
record. Then a simple heuristics is applied whether a referred
function should be added to decoded stack, or not, to avoid reporting
the same function twice (from PC and from the pointer.)

BUG=553
TEST=added to mjsunit/tools/tickprocessor

Review URL: http://codereview.chromium.org/546089

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3673 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Always invoke HeapObjectIterator::has_next() before invoking HeapObjectIterator::next().
This is necessary as ::has_next() has an important side-effect of going to the next
page when current page is exhausted.

And to find if pointers are encodable use more precise data---top of map space, not a number
of pages, as pages might stay in map space due to chunking.

Review URL: http://codereview.chromium.org/552066

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3672 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Review URL: http://codereview.chromium.org/545153

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3671 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Backport optimizations from x64 version to ia32.

Review URL: http://codereview.chromium.org/546087

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3670 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

compiler for all code.

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3669 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

I will revert when the bots have picked this one up.
Review URL: http://codereview.chromium.org/549118

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3668 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

non-optimizing compiler can cope with.  By default it bails out
to the old compiler on encountering a for loop (for performance)
but with this change the --always-fast-compiler flag will enable
functions with for loops to be compiled in the non-optimizing
compiler.  Also enables the non-optimizing compiler on functions
that can be lazily compiled (again only with the flag).
Review URL: http://codereview.chromium.org/552065

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3667 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Review URL: http://codereview.chromium.org/549111

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3666 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Review URL: http://codereview.chromium.org/543121

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3665 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Review URL: http://codereview.chromium.org/545134

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3664 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Review URL: http://codereview.chromium.org/536089

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3663 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Review URL: http://codereview.chromium.org/549109

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3662 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This is a preparation step for including number type information
in the virtual frame. We need a common place where we can update
the number type information of the result of a binary operation
since we should not modify the state of the virtual frame elements
directly.

Review URL: http://codereview.chromium.org/551080

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3661 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

always ambiguous whether it tried to generate fast code, or generate
it quickly.

Review URL: http://codereview.chromium.org/549108

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3660 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

BUG=582
TEST=cctest/test-api/NativeFunctionConstructCall

Review URL: http://codereview.chromium.org/546088

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3659 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Review URL: http://codereview.chromium.org/548069

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3658 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

TBD=sgjesse@chromium.org

Review URL: http://codereview.chromium.org/543120

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3657 ce2b1a6d-e550-0410-aec6-3dcde31c8c00