This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: function-at-a-time processing in C



  Benjamin Chelf <chelf@codesourcery.com> writes:

  > + DEFTREECODE (EXPR_STMT, "expr_stmt", 'e', 1)
  > + DEFTREECODE (COMPOUND_STMT, "compound_stmt", 'e', 1)
  > + DEFTREECODE (DECL_STMT, "decl_stmt", 'e', 1)
  > + DEFTREECODE (IF_STMT, "if_stmt", 'e', 3)
  > + DEFTREECODE (FOR_STMT, "for_stmt", 'e', 4)
  > + DEFTREECODE (WHILE_STMT, "while_stmt", 'e', 2)
  > + DEFTREECODE (DO_STMT, "do_stmt", 'e', 2)

  This has serious problems.

  First, where is the documentation?  Yes, I can figure these out
  from my knowledge of C, but I still want documentation.

That's a fair criticism.  Don't blame Ben, though -- blame me somewhat
and the dark ages of the C++ front-end even more.  These nodes have
existed for years in g++, and just making their emergence into
language-independent code.  Ben's just moving stuff. 

There is documentation for these nodes in cp/ir.texi by the way.  Some
parts of that file, at least, will probably want to get promoted out
of the cp directory eventually.

I'll write documentation for these today in the source.

  Second, why is there an IF_STMT?  What does it do that COND_EXPR
  doesn't do?

Well, it's a statement, not an expression.  So, for example, it has a
line number, and a pointer to the next statement.

  Third, why are there separate FOR_STMT, WHILE_STMT, DO_STMT?
  They are all variants of each other.  In fact, they are all special
  cases of LOOP_EXPR.  Using separate tree codes means useless extra code,
  and more difficulty writing optimizers.

It also means a representation that looks more like the source
program.  That's essential in some cases (templates), and useful for
folks who want to write other tools based on the front-ends that
aren't compilers.  Of course, when these become RTL, they do all
become the same thing.

As above, these things are statements, not expressions.

  > + /* A SCOPE_STMT marks the beginning or end of a scope.  If
  > +    SCOPE_BEGIN_P holds, then this is the start of a scope.  If
  > +    SCOPE_END_P holds, then this is the end of a scope.  If
  > +    SCOPE_NULLIFIED_P holds then there turned out to be no variables in
  > +    this scope.  The SCOPE_STMT_BLOCK is the BLOCK containing the
  > +    variables declared in this scope.  */
  > + DEFTREECODE (SCOPE_STMT, "scope_stmt", 'e', 1)

  This is strange way to represent a scope.

Agreed -- but it turns out to be strangely practical.

  > + DEFTREECODE (CASE_LABEL, "case_label", 'e', 2)

  What are the two operands?

Here's what's in ir.texi:

@item CASE_LABEL

Use to represent a @code{case} label, range of @code{case} labels, or a
@code{default} label.  If @code{CASE_LOW} is NULL_TREE, then this is a a
@code{default} label.  Otherwise, if @code{CASE_HIGH} is NULL_TREE, then
this is an ordinary @code{case} label.  In this case, @code{CASE_LOW} is
an expression giving the value of the label.  Both @code{CASE_LOW} and
@code{CASE_HIGH} are @code{INTEGER_CST} nodes.  These values will have
the same type as the condition expression in the switch statement.

Otherwise, if both @code{CASE_LOW} and @code{CASE_HIGH} are defined, the
statement is a range of case labels.  Such statements originate with the
G++ extension that allows users to write things of the form:
@example
case 2 ... 5:
@end example
The first value will be @code{CASE_LOW}, while the second will be
@code{CASE_HIGH}.

  A final problem is that Java (when using the source code parser)
  also represents methods as trees.  Java should use the same tree
  nodes as C/C++.  That means java/java-tree.def should be partially
  merged with tree.def - though that is primarily the job of the
  Java people.

That's the discussion that David and RTH weighed in on.  I'm surprised
that people are eager for this stuff to be shared, because I bet that
there will be little semantic differences between languages.  Still,
it seems reasonable to me.  I'll reorganize the code a bit today.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]