function-at-a-time processing in C

[Mark Mitchell]

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

    Richard> In summary, the way I see front ends working in the
    Richard> future is they parse into tree structures that bear
    Richard> striking resemblance to the source text.  They verify
    Richard> semantics, finish name resolution and other sundry
    Richard> bookkeeping as needed, and then replace language-specific
    Richard> tree nodes with language-independant tree nodes
    Richard> (i.e. lower the IL just a smigin) and hand off the whole
    Richard> function to the middle end.

I agree 100%.

But you've confused me because we're trying to do exactly what you
suggest for C!  Parse C into something that looks like C (including
FOR_STMTs, etc.).  Those things are C-specific, so they go in
c-common.def.  For now, we'll turn this stuff into RTL.  But, later,
when the all-singing all-dancing language-independent tree stuff is
ready we can turn it into that instead.

I think we need to do this incrementally in order to get it done at
all.  I know that all we can do right now is work on this incremental
chunk.  I think it will help folks a lot; it will help reduce the
amount of code in the compiler, provide a way to use the C front-end
the way people are already using the C++ front-end with other tools,
allow some tree-based optimizations on the C representation, and
accomplish the goal you stated above of generating "tree sturctures
that bear striking resemblance to the source text".

Perhaps some aspects (IF_STMT?) could be used outside of C.  Perhaps
not; see Per's argument that these should be COND_EXPRs.  Perhaps the
lowering phase you mention would turn IF_STMTs into COND_EXPRs.  So
why clutter the language-independent code with IF_STMTs if we don't
want them anyhow in the middle end?

So, I'm lost; I feel like your sentitments (which mirror mine) are
precisely the reasons I didn't think we should put this stuff in
language-independent code.

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