Add a pass for the fast compiler to label expression nodes....

Add a pass for the fast compiler to label expression nodes.

This change adds a post-order numbering to AST nodes that
are relevant for the fast code generator. It is only invoked
together with the fast compiler. 

Also changed the ast printer to print the  numbering for 
testing purposes if it is present.


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

[Kevin Millikin (Chromium), 2010-01-28 15:46:58]

I think you should rename PostOrderNumbering(literal) ==> AstLabeler() and
Process() ==> Label(literal).

There are three visual studio build files in our tree
tools/visual_studio/v8_base.vcproj, v8_base_arm.vcproj, and v8_base_x64.vcproj
that you should update to add the new .h and .cc files.

http://codereview.chromium.org/553134/diff/8001/8008
File src/data-flow.cc (right):

http://codereview.chromium.org/553134/diff/8001/8008#newcode32
src/data-flow.cc:32: #include "parser.h"
I'm surprised you need parser.h?  And ast.h is included already in data-flow.h.

http://codereview.chromium.org/553134/diff/8001/8008#newcode171
src/data-flow.cc:171: // Do nothing.
We actually don't 'support' literals yet.  when we do, this is not correct---we
will emit code for them in some contexts (ie, arguments to a call).

http://codereview.chromium.org/553134/diff/8001/8008#newcode196
src/data-flow.cc:196: void PostOrderNumbering::VisitAssignment(Assignment* expr)
{
The way we compile assignments, they are not binary operations.  There are three
cases: variable (unary) assignments x=<expr>, named property (binary)
assignments <expr0>.name=<expr1>, and keyed property (ternary) assignments
<expr0>[<expr1>]=<expr2>.

In keyed property assignments, we only support properties on this, and we don't
want to visit this as a variable proxy (and number it) because we will not emit
code for it (rather, we'll emit code as part of the parent node, the
assignment).

http://codereview.chromium.org/553134/diff/8001/8008#newcode208
src/data-flow.cc:208: void PostOrderNumbering::VisitProperty(Property* expr) {
We don't 'support' properties yet either.

http://codereview.chromium.org/553134/diff/8001/8009
File src/data-flow.h (right):

http://codereview.chromium.org/553134/diff/8001/8009#newcode49
src/data-flow.h:49: FunctionLiteral* fun_;
This isn't really part of the state.

http://codereview.chromium.org/553134/diff/8001/8009#newcode52
src/data-flow.h:52: int t_num_;
next_ or next_number_ is a better name than t_num_.

http://codereview.chromium.org/553134/diff/8001/8009#newcode56
src/data-flow.h:56: AST_NODE_LIST(DECLARE_VISIT)
Methods should come before data members, even these macro-generated methods.

[fschneider, 2010-01-28 16:42:05]

Addresses the comments and added the visual studio files.

http://codereview.chromium.org/553134/diff/8001/8008
File src/data-flow.cc (right):

http://codereview.chromium.org/553134/diff/8001/8008#newcode32
src/data-flow.cc:32: #include "parser.h"
On 2010/01/28 15:46:58, Kevin Millikin wrote:
> I'm surprised you need parser.h?  And ast.h is included already in
data-flow.h.

Done.

http://codereview.chromium.org/553134/diff/8001/8008#newcode171
src/data-flow.cc:171: // Do nothing.
On 2010/01/28 15:46:58, Kevin Millikin wrote:
> We actually don't 'support' literals yet.  when we do, this is not
correct---we
> will emit code for them in some contexts (ie, arguments to a call).

Done.

http://codereview.chromium.org/553134/diff/8001/8008#newcode196
src/data-flow.cc:196: void PostOrderNumbering::VisitAssignment(Assignment* expr)
{
On 2010/01/28 15:46:58, Kevin Millikin wrote:
> The way we compile assignments, they are not binary operations.  There are
three
> cases: variable (unary) assignments x=<expr>, named property (binary)
> assignments <expr0>.name=<expr1>, and keyed property (ternary) assignments
> <expr0>[<expr1>]=<expr2>.
> 
> In keyed property assignments, we only support properties on this, and we
don't
> want to visit this as a variable proxy (and number it) because we will not
emit
> code for it (rather, we'll emit code as part of the parent node, the
> assignment).

Done. I changed visiting assignments to follow more closely what we support in
the FastCodeGenSyntaxChecker. I still have to visit 'this' since it represent a
use of the this-variable.

http://codereview.chromium.org/553134/diff/8001/8008#newcode208
src/data-flow.cc:208: void PostOrderNumbering::VisitProperty(Property* expr) {
On 2010/01/28 15:46:58, Kevin Millikin wrote:
> We don't 'support' properties yet either.

Done.

http://codereview.chromium.org/553134/diff/8001/8009
File src/data-flow.h (right):

http://codereview.chromium.org/553134/diff/8001/8009#newcode49
src/data-flow.h:49: FunctionLiteral* fun_;
On 2010/01/28 15:46:58, Kevin Millikin wrote:
> This isn't really part of the state.

Done.

http://codereview.chromium.org/553134/diff/8001/8009#newcode52
src/data-flow.h:52: int t_num_;
On 2010/01/28 15:46:58, Kevin Millikin wrote:
> next_ or next_number_ is a better name than t_num_.

Done.

http://codereview.chromium.org/553134/diff/8001/8009#newcode56
src/data-flow.h:56: AST_NODE_LIST(DECLARE_VISIT)
On 2010/01/28 15:46:58, Kevin Millikin wrote:
> Methods should come before data members, even these macro-generated methods.

Done.

[antonm, 2010-01-28 17:31:49]

drive-by stylistic nit

http://codereview.chromium.org/553134/diff/2023/1023
File src/data-flow.h (right):

http://codereview.chromium.org/553134/diff/2023/1023#newcode41
src/data-flow.h:41: explicit AstLabeler() : next_number_(0) {}
nit: no need in explicit

[fschneider, 2010-01-29 09:42:31]

http://codereview.chromium.org/553134/diff/2023/1023
File src/data-flow.h (right):

http://codereview.chromium.org/553134/diff/2023/1023#newcode41
src/data-flow.h:41: explicit AstLabeler() : next_number_(0) {}
On 2010/01/28 17:31:50, antonm wrote:
> nit: no need in explicit

Done.