low level optimization

[Mike McGaughey]

bhoughto at bishop.intel.com (Blair P. Houghton) writes:

>In article <21868 at lanl.gov> jlg at cochiti.lanl.gov (Jim Giles) writes:
>>I don't understand why you continue to hang on like grim death
>>to the fiction that dependent compilation satisfies the requirements
>>of the standard.

>I haven't seen anyone state such a thing.  What I have
>seen is plenty of statements that equate to the standard's
>requirement that a conforming program be translatable by
>a conforming implementation into a form that can be used
>to produce the output associated with a given input.  It's
>just tough luck if this prevents you from expecting
>a certain optimization to be applied when you compile
>in strictly conforming mode.

And, in fact, it doesn't - if your system wants to do 'serious'
interprocedural analysis while still allowing seperate, order
independent compilation, there's nothing to stop it from adding an
extra table to the object file describing the properties of that object
file, and using a clever linker (post-compiler?) to sort all that
information out.

Any specification that non-static names are the only 'standard'
inter-module information available applies only to C source, not object
modules - after all, who ever expected object code to be portable?  All
we know is that they must support *at least* the information required
by C.  There's no reason why .o files can't consist of pure RTL.  Or C
source code, for that matter.  Although that *would* require a better
linker :).

Not that I've read the ANSI spec - I'm too poor.

Cheers,

    Mike.

ps: the MIPS compilers (which are pretty good :) provide this option -
you can produce ucode files instead of .o files (independantly); the
ucode linker provides global optimisation.
-- 
Mike McGaughey			AARNET:	mmcg at bruce.cs.monash.oz.au

"His state is kingly; thousands at his bidding speed,
 And post o'er land and ocean without rest."		- Milton.