Fix number of parameters passed into PrepareCallCFunction in code age stubs

Fix number of parameters passed into PrepareCallCFunction in code age stubs

In r16710 Additional parameter (Isolate) was added to parameter lists of some native functions called from the generated code. However, corresponding PrepareCallCFunction arguments changed only on i32. This CL updates other architectures to match actual value.

BUG=None
LOG=None
R=dcarney@chromium.org

Committed: https://code.google.com/p/v8/source/detail?r=18379

[Sven Panne, 2013-11-20 13:14:08]

Is this CL still necessary? What test cases are crashing? If there are none,
please add some.

[yurys, 2013-11-20 14:03:21]

On 2013/11/20 13:14:08, Sven Panne wrote:
> Is this CL still necessary? What test cases are crashing? If there are none,
> please add some.

With current implementation of {Prepare}CallCFunction the change doesn't change
the behavior as on the affected platforms first N arguments are passed in
registers, e.g. on x64 first 4 parameters will be passed in registers and it
doesn't make any difference whether you pass 0,1,2, or 3 as long as the number
of actual params is less than 4. The only platform where passing 1 and 2 makes a
difference is ia32 where all arguments are passed on the stack. I stumbled upon
this problem while reading the code and trying to understand why we pass 2
parameters in registers but tell PrepareCallCFunction that it should expect only
1. This is confusing. As I said it works fine with the existing implementation
but should PrepareCallCFunction change the treatment of num_reg_arguments the
inconsistency this patch is addressing may result in some hard to catch bugs.
Since the patch doesn't affect generated code I don't see what test I could
provide.

[yurys, 2013-12-18 08:46:30]

Sven, does the rationale above makes sense to you or this is a too minor thing
and we'd better drop this change?

[dcarney, 2013-12-18 09:22:28]

On 2013/12/18 08:46:30, yurys wrote:
> Sven, does the rationale above makes sense to you or this is a too minor thing
> and we'd better drop this change?

I'd say land this

[yurys, 2013-12-18 09:23:58]

On 2013/12/18 09:22:28, dcarney wrote:
> On 2013/12/18 08:46:30, yurys wrote:
> > Sven, does the rationale above makes sense to you or this is a too minor
thing
> > and we'd better drop this change?
> 
> I'd say land this

Good, need OWNER's approval then.

[dcarney, 2013-12-18 09:45:39]

On 2013/12/18 09:23:58, yurys wrote:
> On 2013/12/18 09:22:28, dcarney wrote:
> > On 2013/12/18 08:46:30, yurys wrote:
> > > Sven, does the rationale above makes sense to you or this is a too minor
> thing
> > > and we'd better drop this change?
> > 
> > I'd say land this
> 
> Good, need OWNER's approval then.

right, sorry

lgtm

[yurys, 2013-12-20 07:46:09]

Committed patchset #1 manually as r18379 (presubmit successful).