Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbnewsh!daw
From: daw@cbnewsh.att.com (David Wolverton)
Newsgroups: comp.lang.c
Subject: Re: C common practice. (was: low level optimization)
Message-ID: <1991Apr29.220139.28983@cbnewsh.att.com>
Date: 29 Apr 91 22:01:39 GMT
References: <22354@lanl.gov> <16815@chaph.usc.edu> <22649@lanl.gov>
Organization: AT&T Bell Labs, Holmdel, NJ
Lines: 23

In article <22649@lanl.gov>, jlg@cochiti.lanl.gov (Jim Giles) writes:
> One of the assumptions (which is still valid most places) is that
> no interprocedural analysis is done - even _within_ a file, even 
> though the language permits such optimizations.  The result is that
> there really is a tendency to maintain C code as numerous separate
> files.  ...[stuff deleted]...
> I don't maintain that keeping code in separate file is necessarily
> bad or good.  But to pretend that it is not common practice is to 
> ignore reality.  This common practice may in (the near) future result 
> in less efficient code because of missed optimization.

I can't say about "most places", but I _can_ say that we
built a commercially-available 3B2 C compiler here in 1986
that did some interprocedural stuff within a source file.

Our biggest customer was a project with _thousands_ of
functions, one per file.  We tried mightily to get them
to group related functions into a single file, but their
"project methodology" wouldn't allow it.  So they could
never take advantage of that group of optimizations.

Dave Wolverton
AT&T Bell Labs