This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Intermodule constant propagation
> From: Andrew Pinski <pinskia@physics.uc.edu>
> Date: Mon, 24 Nov 2003 15:17:58 -0800
> On Nov 24, 2003, at 13:52, Geoff Keating wrote:
> > If anyone wants to work on this (it's mostly a question of taking a
> > patch to gcc.c from Apple's compiler, porting it to FSF GCC, and
> > tidying it up), I can point them at the appropriate code...
>
>
> I will do it, just point me to where.
It's more-or-less these changes to Apple's tree available at
cvs -d :pserver:anonymous@anoncvs.opensource.apple.com:/cvs/root \
co gcc3/gcc/gcc.c
with this entry in .cvspass:
:pserver:anonymous@anoncvs.opensource.apple.com:/cvs/root Ay=0=a%0bZ
----------------------------
revision 1.164.2.12.2.8
date: 2003/07/16 22:34:23; author: ctice; state: Exp; lines: +158
-50
Radar 3289013. Fix spec-branch driver to deal properly with compiling
multiple
source files at once: end restrictions of extensions for extra link
files;
allow mixing of different language source files on command line; only
attempt
to compile multiple files at once for C or objective-C; make
-save-temps flag
work properly with this stuff.
Approved by Mike Stump.
----------------------------
revision 1.164.2.12.2.5
date: 2003/06/15 18:48:21; author: ctice; state: Exp; lines: +16
-12
Fix driver problem so that IMI link files fix is only applied when
multiple sour
ce
files are passed to driver.
Approved by Dale Johannesen
----------------------------
revision 1.164.2.12.2.4
date: 2003/06/14 22:32:24; author: ctice; state: Exp; lines: +37 -6
This addresses the problem (introduced with IMI) of the driver
attempting to han
d
the link files to the compiler along with the source files; now it
sends the lin
k
files to the linker instead. It addresses radars 3176533 and 3289013.
Approved by Geoff, Dale, & Stuart (in some combination).
----------------------------
revision 1.164.2.12.2.1
date: 2003/05/20 19:17:14; author: gkeating; state: Exp; lines: +52
-8
Inter-Module Inlining.
Bug #: 3197786
Reviewed by: dale
----------------------------
I think there might be a few bugs left, but it basically works,
certainly it works well enough for spec. What it's supposed to do is:
- 'gcc foo.c bar.c -o foo' takes the two .c files, builds a single .s
file, sends that to the assembler and the resulting .o to the
linker.
- 'gcc -save-temps foo.c bar.c -o foo' turns each .c file into a .i
file, producing foo.i and bar.i, then builds a single .s file from them.
- 'gcc foo.c bar.c -S' produces two .s files, foo.s and bar.s.
- likewise, 'gcc foo.c bar.c -c' produces two .o files.
- 'gcc foo.c bar.c -S -o result.s' produces one .s file.
- likewise, 'gcc foo.c bar.c -c -o result.o' produces one .o file
- 'gcc foo.c bar.c -E' is an error, just like now (I hope)
- 'gcc foo.c bar.c -E -o result.i' is an error, just like now
Note that none of this has anything to do with optimisation levels. It's
done because more error checking is possible when the compiler can see
multiple source files at a time; this fixes the age-old problem of
'how can I check that my prototypes are consistent between source
files', and the brand-new problem of 'my program built fine when I
didn't use intermodule inlining, but the compiler complained when I
switched it on, and my build takes 8 hours and 3G of RAM at -O3,
please help!'
- This happens for objc files too. the behaviour with C++ files is
not changed, since we don't have IMA for C++ yet. (One day we will,
but it's a much-different implementation, because C++ has the One
Definition Rule.)
--
- Geoffrey Keating <geoffk@geoffk.org>