Begin using the top-level code generator for code that is inside...

Begin using the top-level code generator for code that is inside
directly-applied function literals that are themselves compiled with
the top-level code generator.

The choice is guarded by a test that the function is anonymous (thus
not expected to be recursive) and not in a loop.

A compilation hint is set in the shared function info and used to make
the choice.

[Søren Thygesen Gjesse, 2009-11-03 13:57:47]

LGTM

http://codereview.chromium.org/341081/diff/1/11
File src/arm/fast-codegen-arm.cc (right):

http://codereview.chromium.org/341081/diff/1/11#newcode830
Line 830: lit->mark_as_fast();
As this logic is duplicated in all three code generators how about moving it to
the FunctionLiteral passing the current loop_depth (or the
FastCodeGenerator/CodeGenerator object)?

http://codereview.chromium.org/341081/diff/1/4
File src/ast.h (right):

http://codereview.chromium.org/341081/diff/1/4#newcode1350
Line 1350: bool is_marked_as_fast() { return try_fast_codegen_; }
Why not just the standard accessor names?

  void set_try_fast_codegen(bool try_fast_codegen)
  bool is_try_fast_codegen()

http://codereview.chromium.org/341081/diff/1/9
File src/fast-codegen.cc (right):

http://codereview.chromium.org/341081/diff/1/9#newcode359
Line 359: increment_loop_depth();
How placing the increment_loop_depth()/decrement_loop_depth() in a stack
allocated class to ensure they are paired. Maybe the other ASSERT in codegen
will catch this anyway.

[fschneider, 2009-11-03 14:10:13]

LGTM.

http://codereview.chromium.org/341081/diff/1/11
File src/arm/fast-codegen-arm.cc (right):

http://codereview.chromium.org/341081/diff/1/11#newcode97
Line 97: ASSERT(loop_depth() == 0);
Why this duplicate ASSERT? (also on ia32, x64)

[Kevin Millikin (Chromium), 2009-11-03 14:16:09]

http://codereview.chromium.org/341081/diff/1/11
File src/arm/fast-codegen-arm.cc (right):

http://codereview.chromium.org/341081/diff/1/11#newcode97
Line 97: ASSERT(loop_depth() == 0);
On 2009/11/03 14:10:13, fschneider wrote:
> Why this duplicate ASSERT? (also on ia32, x64)

We should not be in a loop before we compile the body, and we should not be in a
loop afterward either.

http://codereview.chromium.org/341081/diff/1/11#newcode830
Line 830: lit->mark_as_fast();
On 2009/11/03 13:57:47, Søren Gjesse wrote:
> As this logic is duplicated in all three code generators how about moving it
to
> the FunctionLiteral passing the current loop_depth (or the
> FastCodeGenerator/CodeGenerator object)?

That's a good idea.  For now the check is pretty simple, so I'll leave it out of
the AST.

http://codereview.chromium.org/341081/diff/1/4
File src/ast.h (right):

http://codereview.chromium.org/341081/diff/1/4#newcode1350
Line 1350: bool is_marked_as_fast() { return try_fast_codegen_; }
On 2009/11/03 13:57:47, Søren Gjesse wrote:
> Why not just the standard accessor names?
> 
>   void set_try_fast_codegen(bool try_fast_codegen)
>   bool is_try_fast_codegen()
> 

I was being too cute.  I didn't see the need yet to change it back to false
since that's the default.  I'll just go with the standard accessor names, as you
suggest.

http://codereview.chromium.org/341081/diff/1/9
File src/fast-codegen.cc (right):

http://codereview.chromium.org/341081/diff/1/9#newcode359
Line 359: increment_loop_depth();
On 2009/11/03 13:57:47, Søren Gjesse wrote:
> How placing the increment_loop_depth()/decrement_loop_depth() in a stack
> allocated class to ensure they are paired. Maybe the other ASSERT in codegen
> will catch this anyway.

I thought about that, but it seemed too complicated for this.  I'll leave it
like this for now and reconsider when I do the other loops.