Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!rutgers!cmcl2!lanl!cochiti.lanl.gov!jlg
From: jlg@cochiti.lanl.gov (Jim Giles)
Newsgroups: comp.lang.c
Subject: Re: low level optimization
Message-ID: <21964@lanl.gov>
Date: 19 Apr 91 16:57:44 GMT
References: <1991Apr17.225944.15261@zoo.toronto.edu> <1991Apr18.190403.29049@Think.COM> <21846@lanl.gov> <1991Apr19.055002.3399@Think.COM>
Sender: news@lanl.gov
Organization: Los Alamos National Laboratory
Lines: 28


> [...]       (why does everyone keep calling this interprocedural analysis?
> that usually refers to optimization across procedures within the same
> file) [...]

Oh.  Quite so.  Only the common practice of C programmers putting each
function in its own separate file makes the mistake double easy to fall
into.  Not to mention the obvious fact that the implementation details
of interprocedure and intermodule analysis would be almost identical
from the implementors point of view.


> Once you invoke the implementation's extension that does inter-module
> optimization [...]
> [...] you have ventured outside the scope of the standard, just as if you
> had invoked a compiler option that enables some implementation-specific
> feature.

That's what I keep trying to point out.  Thank heavens for someone 
finally joining the discussion who understands the issue.  Further,
I agree that the standard could have been just subtly reworded to 
eliminate the objection just stated.  But, the fact remains that it
was worded the way it was (and probably for reason - vendors would
like to continue to be able to distribute only object code and if
large pieces of the object code are interdependent, this would make
incremental fixes and distributions of such much more difficult).

J. Giles