This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Unit at time compilation mode III
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Geert Bosch <bosch at gnat dot com>
- Cc: Richard dot Earnshaw at arm dot com, Jan Hubicka <jh at suse dot cz>, Fergus Henderson <fjh at cs dot mu dot oz dot au>, Richard Henderson <rth at redhat dot com>, Zack Weinberg <zack at codesourcery dot com>, gcc-patches at gcc dot gnu dot org
- Date: Thu, 13 Feb 2003 09:49:08 +0000
- Subject: Re: Unit at time compilation mode III
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
>
> On Wednesday, Feb 12, 2003, at 11:40 America/New_York, Richard Earnshaw
> wrote:
> > It's true that unit-at-once could be interpreted to mean multiple
> > files.
> > But if we enabled that, surely we'd want a separate flag for that to
> > distinguish it over doing whole files at once. I can imagine people
> > being
> > concerned about memory usage in the case where we allowed multiple
> > files.
>
> Unit-at-once seems the right term. In particular, when Ada will use
> this,
> a compilation may include many files for generics (=templates),
> sub-units etc.
> Similarly, when you would use #include files in your C program, a single
> compilation would also compile multiple files.
>
Both of these are what I really think of as file-at-once.
unit-at-once (or inter-file) is more what I would expect to happen if the
user specified
gcc -Oxxx -finter-file a.c b.c c.c d.c
etc. The compiler can then do inter-file optimizations between all the .c
files on the command line. If we can see entire subtrees of the
call-graph then we can do significantly more powerful optimizations, and
particularly get a better idea of what aliasing or other memory updates
may be involved.
R.