Support for property access (named, keyed) in the fast compiler....

Support for property access (named, keyed) in the fast compiler.

The generated code is similar to the existing code, but we never
inline any IC code in the fast compiler.



Committed: http://code.google.com/p/v8/source/detail?r=3152

[Kevin Millikin (Chromium), 2009-10-27 15:08:54]

LGTM.

http://codereview.chromium.org/337045/diff/1001/2001
File src/ia32/fast-codegen-ia32.cc (right):

http://codereview.chromium.org/337045/diff/1001/2001#newcode507
Line 507: Comment cmnt(masm_, "[ Load from named Property");
These comments in the generated code might not be necessary.

http://codereview.chromium.org/337045/diff/1001/2001#newcode516
Line 516: __ add(Operand(esp), Immediate(kPointerSize));
You might consider omitting this, and using the drop-and-move pattern to move
eax to the expression's location after the if...then...else.

[fschneider, 2009-10-27 15:40:03]

http://codereview.chromium.org/337045/diff/1001/2001
File src/ia32/fast-codegen-ia32.cc (right):

http://codereview.chromium.org/337045/diff/1001/2001#newcode507
Line 507: Comment cmnt(masm_, "[ Load from named Property");
On 2009/10/27 15:08:54, Kevin Millikin wrote:
> These comments in the generated code might not be necessary.

Done. (also for x64, arm)

http://codereview.chromium.org/337045/diff/1001/2001#newcode516
Line 516: __ add(Operand(esp), Immediate(kPointerSize));
On 2009/10/27 15:08:54, Kevin Millikin wrote:
> You might consider omitting this, and using the drop-and-move pattern to move
> eax to the expression's location after the if...then...else.


Done. (also on x64, arm)

Right. This is better for the common case (location != NOWHERE). The only case
where we generate an extra pop() is a keyed load with location NOWHERE.