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

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Jason" == Jason Merrill <jason@cygnus.com> writes:

    >> Interesting that you think so.  I thought about this the other
    >> way: these nodes have structure that very closely matches C's
    >> syntax and semantics.  For example, FOR_STMT has four children:
    >> the initialization, test, increment, and body.  That might well
    >> not match up with what other languages might want in an
    >> iteration statement.

    >> Following on later will be bits to build these things, and bits
    >> to turn them into RTL.  Turning them into RTL is also going to
    >> have C-like semantics.

    Jason> I think this is a mistake.  The point of functions-as-trees
    Jason> is to be able to do optimizations on trees rather than RTL;
    Jason> for this to be reasonable, we need to have a notion of
    Jason> language-independent trees, or any optimizations would be
    Jason> limited to whatever frontend happened to implement them.

I disagree; see Richard's comments for a great description of how
things ought to work.

First, I think we want language-specific trees.  Then, we want
language-independent trees.  Finally, we want RTL, or some other
low-level representation.  (SGI's WHIRL representation is attractive
in that all representations are actually the same, so the lowering is
more gradual than in GCC, where trees disappear to be replaced with
RTL.)

The high-order bit is there are *two* points of functions-as-trees.
One is to optimization on trees.  Another is do produce front-ends
that, like the EDG front-end, can be used in free software other than
compilers.

Front-ends should do parsing, semantic analysis, and so forth to
produce a faithful, but easily machine-readable, representation of the
source program.  Then, this representation should be transformed into
something the optimizers can work on easily.  (At present that's RTL;
some day, I fully agree that it should be a language-independent tree
representation amenable to better high-level optimization.)  Finally,
code should be emitted.

Trying to go to the eventual language-independent representation now
is going to be very hard.  And going there directly from the C
front-end means you'll miss the benefits of producing the first,
closest-to-source-level intermediate format.

That's why we put this stuff in c-common.def; I in no way claimed it's
the format that should be used by all front-ends, or the one that
should be used for tree-based optimizations.  It's just supposed to be
the one that represents C most faithfully.

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