Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!ucla-cs!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: <21812@lanl.gov> Date: 18 Apr 91 16:45:39 GMT References: <15828@smoke.brl.mil> <21527@lanl.gov> <15870@smoke.brl.mil> <21660@lanl.gov> <1991Apr17.225944.15261@zoo.toronto.edu> Sender: news@lanl.gov Organization: Los Alamos National Laboratory Lines: 25 In article <1991Apr17.225944.15261@zoo.toronto.edu>, henry@zoo.toronto.edu (Henry Spencer) writes: |> [...] You do interprocedural |> analysis across all source files supplied to a single invocation of the |> compiler, [...] And, if you subsequently change _some_ of those source files? What then? Under this model, you'd have to recompile _all_ the others that were originally compiled together. This violates one of the principle reasons to have separate compilation to begin with - the elimination of the needto recompile most of your code every time you change a piece of it. Note: I'm not arguing that what you suggest is a bad idea. I think personally that what you've said here is a good way to improve performance. I'm just pointing out that it _does_ violate the standards of both Fortran and C which are defined to be separately compiled. There are a lot of _non-standard_ ways to improve performance. But, it is always a mistake to allow someone to claim that any of these are really standard after all.` Finally, I don't have access to any production quality compilers which do interprocedural analysis for either Fortran or C. Fortran doesn't need the feature as much as C does. J. Giles