This is the mail archive of the
mailing list for the GCC project.
Re: Language-independent functions-as-trees representation
- From: Steven Bosscher <s dot bosscher at student dot tudelft dot nl>
- To: Jason Merrill <jason at redhat dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: 20 Jul 2002 22:09:53 +0200
- Subject: Re: Language-independent functions-as-trees representation
- References: <firstname.lastname@example.org>
Op za 20-07-2002, om 14:47 schreef Jason Merrill:
> In a previous thread, Diego has suggested that inlining would be done on
> language-dependent trees. I think this is a mistake; IMO it should be done
> at the SIMPLE level. Requiring the inliner to know about frontend trees is
That depends on what you're trying to inline. I know for sure that it
would be *mandatory* for an efficient inliner for Fortran 95 to know
about the front end.
For example, subroutines, functions or user defined operators can take
whole arrays or (worse!) array sections as their actual arguments.
Sometimes we need to copy in/out these arguments in temporary arrays,
but if the operator or function can be inlined, we can scalarize the
whole think inline and avoid the temporary arrays.
Inlining of user operators could be a big win, and users probably expect
inlining of statement functions or nested subroutines/functions.
Once we've generated SIMPLE code, we've lost the opportunity to do this
kind of inlining.