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

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Richard" == Richard Henderson <rth@cygnus.com> writes:

    Richard> Do me a favor and arrange the code in the C and C++ front
    Richard> ends to have a single point of hand-off between the
    Richard> entire function as one big chain of language-dependant
    Richard> tree nodes and absolutely everything to do with rtl.
    Richard> This will make our future goals easier to achieve.

Definitely.

    Richard> I'm not sure how far you are from this architecture
    Richard> currently.  Expanding trees to rtl appears to be
    Richard> curiously intertwined between tsubst_expr and
    Richard> building_stmt_tree in the C++ front end;

Yes indeed, the building_stmt_tree stuff is very ugly.  Ben's next
patch, already in draft stage, is actually to fix exactly that problem
and unintertwine the tree-building vs. tree-expanding stuff.  (The
current situation is sort of a historical accident; there's a reason
for why it's the way it is, but not a good engineering reason!)

Here's the eventual plan:

  - expand_body turns an entire function-as-tree into RTL
  - it does this by invokving the recursive expand_stmt function on
    the top-level block of the function
  - expand_stmt handles all the various IF_STMT, FOR_STMT, stuff
    calling expand_begin_cond, expand_end_cond, etc.
  - the expansion stuff doesn't check building_stmt_tree, or, more
    generally, make any callbacks into the rest of the front-end.
    Basically, the statements tree represents the source program
    completely.

Some day, we can have expand_body turn everything into
language-independent tree instead, optimize like mad, and then spit
out RTL from there.  That will be a relatively compact change; the
semantic parts of the front-ends won't even have to know.

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