Re: Final intermodule patch

[Geoff Keating <geoffk at geoffk dot org>]

> Date: Mon, 14 Jul 2003 11:07:51 +0100
> From: Nathan Sidwell <nathan@codesourcery.com>

> Geoff,
> I think the command line option handling for the (excellent) intermodule
> mode is wrong.
> 
> 	gcc -c file1.c file2.c
> gets me separate file1.o and file2.o objects.
> 	gcc -c file1.c file2.c -o foo.o
> gets me intermodule work. Yet I've not changed any *optimization*
> option.

Right.  My patch does not implement any optimisations, and it is not a
change to the optimizers.  You do not get better code generation just
because you use it; you must use -Osomething too.


> I'd guess users (we should canvas some) would think of intermodule stuff
> as an optimization, and be surprised that it is not triggered by a -O
> level (say -O4?) or a -fintermodule flag. Here's a pop quiz
> 	You want to turn inter-file analysis on, do you
> 	a) Turn the optimization level way up
> 	b) Specify the name of the intermediate output file?

This is a misconception about what my patch does.

> I notice that the manual just says,
> 	If you specify @option{-o} when compiling more than one input file,
> 	or you are producing an executable file as output, all the source
> 	files on the command line will be compiled at once.'
> what does this tell me? Is
> 	gcc file1.c file2.c -o a.out -O2
> the same as
> 	gcc file1.c file2.c -o a.o -O2 -c
> 	gcc a.o
> -no. The latter does intermodule stuff but the former does not. 'at
> once' is being used with two different meanings in the one sentance![1]
> You'll notice we've now made the options non-compoundable. Unless I
> misgrepped I could find nothing in the invoke.texi file about the
> advantages or disadvantages of 'compiling at once'

Rats.  That's a bug.  It was supposed to work the way the
documentation says, but I couldn't make it work, and forgot to change
the documentation back.

> The use of this patch also affects the downstream tools used to process
> the object file(s). Now their invokations need to be modified to take a
> single input file, rather than a collection of object files.

Yes.  That's why my patch supports -O0 as well as -O3: it lets you do
debugging without changing your build system.

> IMHO, intermodule mode should be an optimization level, and produce
> separate output files per input file. Thus the user merely needs to add
> or remove the appropriate optimization flag from the compile line - rather
> than tweaking all subsequent commands too.
...
> We could fudge multi-file output for now by putting all the code in one
> output file, and emitting empty stubs for the remaining ones. Then users
> will not have to change when we do do separate output files.

I don't understand why you think that having one command take multiple
input files and produce multiple output files is an improvement over a
command that takes multiple input files and produces a single output file.

> [1] A pedant points out that the compiler will compile your source 'at once'
> even if you do not specify the name of an output file -- it doesn't sit
> there humming to itself for a few minutes before starting the work!

It does wait to compile the *second* file.  That's why I said "all
your source".

-- 
- Geoffrey Keating <geoffk@geoffk.org>