Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!fernwood!uupsi!cmcl2!lanl!cochiti.lanl.gov!jlg From: jlg@cochiti.lanl.gov (Jim Giles) Newsgroups: comp.lang.c Subject: Re: C common practice. (what it really is) Message-ID: <22846@lanl.gov> Date: 29 Apr 91 16:19:10 GMT References: <1991Apr27.024634.586@convex.com> Sender: news@lanl.gov Organization: Los Alamos National Laboratory Lines: 20 In article <1991Apr27.024634.586@convex.com>, grogers@convex.com (Geoffrey Rogers) writes: |> In article tmb@ai.mit.edu (Thomas M. Breuel) writes: |> >compile, and, with most compilers, you inhibit all global optimization. |> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |> Huh???? What do you mean by global optimization? Most texts on optimization |> consider global optimization to be between basic blocks within a procdure. |> Having one function per source file does not inhibit this. Everything |> else that you said is true/good common sense. As uncharacteristic as it is for me to defend people that I disagree with, it is legitimate to refer to the use of IM analysis to improve optimization of global data and procedure arguments as 'global optimization'. Is is also true that in the field of compiler construction, the term is use exclusively to mean optimization of all code _within_ a given compilation unit but _across_ basic block boundaries. The language is (unfortunately) used both ways in the programming community as a whole. Nothing you can do about it but grin and bear it. J. Giles