Refactor PropertyCallbackInfo & FunctionCallbackInfo, part 3.

Refactor PropertyCallbackInfo & FunctionCallbackInfo, part 3.

This CL starts using positive array indices instead of negative array indices
for the PropertyCallbackInfo and FunctionCallbackInfo fields. Also, the indices
match now, so they can be unified in the next step.

BUG=
R=dcarney@chromium.org, mstarzinger@chromium.org

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

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

[marja, 2013-09-27 09:21:06]

dcarney, ptal

[dcarney, 2013-09-27 09:27:16]

lgtm

[marja, 2013-09-27 09:38:03]

mstarzinger, ptal.

Pitch for this one: "positive array indexes instead of negative array indexes"!

[haitao.feng, 2013-09-27 11:28:53]

It will be great if you could use StackArgumentsAccessor for all the argument
access from rsp or rbp for X64 in this CL. Please see
https://codereview.chromium.org/22267005/patch/24001/25010 for the changes I
have done over the recent commit. 

Or I could upload a patchset for the argument access in this CL once it is
landed as danno has reviewed the other parts of argument accessing at
https://codereview.chromium.org/22267005/.

[marja, 2013-09-27 11:38:18]

On 2013/09/27 11:28:53, haitao.feng wrote:
> It will be great if you could use StackArgumentsAccessor for all the argument
> access from rsp or rbp for X64 in this CL. Please see
> https://codereview.chromium.org/22267005/patch/24001/25010 for the changes I
> have done over the recent commit. 
> 
> Or I could upload a patchset for the argument access in this CL once it is
> landed as danno has reviewed the other parts of argument accessing at
> https://codereview.chromium.org/22267005/.

I'm not sure if StackArgumentsAccessor is the right way to go:

With StackArgumentsAccessor:

int offset = argc + kFastApiCallArguments;
__ movq(args.GetArgumentOperand(offset - FCA::kContextSaveIndex), rsi);

Without StackArgumentsAccessor:
__ str(cp, MemOperand(sp, FCA::kContextSaveIndex * kPointerSize));

I think the latter is less obscure regarding computing the index. danno, wdyt?

[danno, 2013-09-27 11:50:34]

Please do use the StackArgumentsAccessor. It's not just a question of code
simplicity, the StackArgumentsAccessor is necessary to get parameter access to
work without special casing for the x32 port of the x64 code.

[danno, 2013-09-27 11:50:34]

Please do use the StackArgumentsAccessor. It's not just a question of code
simplicity, the StackArgumentsAccessor is necessary to get parameter access to
work without special casing for the x32 port of the x64 code.

[haitao.feng, 2013-09-27 12:11:12]

Thanks danno for the explanation.

The x32 port of rebase with your "Refactor PropertyCallbackInfo &
FunctionCallbackInfo, part 2" is at
https://github.com/fenghaitao/v8/commit/ce471468e782c854e24186ec331bc8304373eee4.
Please ignore the x32 codes as they are generated from x64 by a script.

[haitao.feng, 2013-09-27 12:15:31]

Sorry, it is
https://github.com/fenghaitao/v8/commit/badbe6839183e943558ea93341b8bd9e27612749.

[Michael Starzinger, 2013-09-27 12:19:55]

LGTM (if comments about StackArgumentsAccessor are addressed).

[marja, 2013-09-27 13:14:29]

Alright, so the end result should be that x64 uses StackArgumentAccessor.

haitao.feng: We can do any of these:
1) I land this as is, you rebase your CL (which starts using
StackArgumentAccessor) on top
2) I start using StackArgumentAccessor in this CL (merge parts of your CL into
it)
3) You land your CL first and I rebase on top of it

I won't work on this until next week. What's your preference? If you want to go
ahead and land your CL first, I won't object.

[haitao.feng, 2013-09-27 23:38:20]

I prefer 1). I will upload a separate CL on StackArgumentsAccessor for X64 for
the recent commits:
  1) https://codereview.chromium.org/23903053
  2) your part2 and part3
Could you and dcarney help me review it next week?

After that, danno could continue reviewing
https://codereview.chromium.org/22267005/ for the other places.

On 2013/09/27 13:14:29, marja wrote:
> Alright, so the end result should be that x64 uses StackArgumentAccessor.
> 
> haitao.feng: We can do any of these:
> 1) I land this as is, you rebase your CL (which starts using
> StackArgumentAccessor) on top
> 2) I start using StackArgumentAccessor in this CL (merge parts of your CL into
> it)
> 3) You land your CL first and I rebase on top of it
> 
> I won't work on this until next week. What's your preference? If you want to
go
> ahead and land your CL first, I won't object.

[marja, 2013-09-28 13:39:03]

danno, mstarzinger: Are you okay with the plan we have with haitao.feng, i.e.,
I'll land this CL as is, and he'll then make the StackArgumentAccessor change?

[marja, 2013-09-30 14:05:42]

Offline discussion: mstarzinger@ says the plan is fine, so committing this now..

[marja, 2013-09-30 14:10:03]

Committed patchset #3 manually as r17015 (presubmit successful).

[marja, 2013-09-30 15:33:05]

oops, going to revert this to investigate some test failures

[marja, 2013-09-30 16:39:42]

On 2013/09/30 15:33:05, marja wrote:
> oops, going to revert this to investigate some test failures

oops2, this wasn't the guilty commit. Will re-land tomorrow.

[marja, 2013-10-01 09:24:24]

Committed patchset #4 manually as r17032 (presubmit successful).