This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Language-independent functions-as-trees representation
- From: Paul Brook <paul at nowt dot org>
- To: gcc at gcc dot gnu dot org
- Date: Wed, 4 Sep 2002 11:57:41 +0100
- Subject: Re: Language-independent functions-as-trees representation
- References: <wvllm86k1m1.fsf@prospero.cambridge.redhat.com> <20020829211043.GB549@redhat.com> <wvlfzwsaytu.fsf@prospero.cambridge.redhat.com>
On Monday 02 September 2002 10:03 pm, Jason Merrill wrote:
> On Thu, 29 Aug 2002 14:10:43 -0700, Richard Henderson <rth@redhat.com>
wrote:
> > On Fri, Aug 23, 2002 at 01:41:28PM +0100, Jason Merrill wrote:
> >> rth has raised some questions about the advisability of using
> >> COMPOUND_EXPR to chain statements; the current scheme uses TREE_CHAIN
> >> of the statements themselves.
> >
> > Perhaps this can be deferred for now by creating some
> > FOR_EACH_STMT (STMT, START) macros that do the iteration. Then we
> > can replace the iteration implementation more easily later.
>
> Indeed, I've already added a foreach_stmt function to c-simplify.c on the
> bnw-simple-branch.
I haven't looked at the code, but I'd gess this is a language-independant
function used by the optimizers. If so, could you put it in a l-i file,
rather than c-simplify.c. Otherwise It'll just mean more work later. There
are already some functions (eg. deep_copy_node/list) which shouldn't be in
c-simplify.c, It seems silly to add more.
Basically I'm opposed to anything that isn't C specific going into
c-simplify.c because this makes maintenance of other languages (in my case
Fortran95) difficult and requires unneccessary code duplication.
Paul Brook