Re: And speaking of fast compilers...

pardo@cs.washington.edu (David Keppel) writes:


>I talked more with the author of the 7,000-line program. He says the
>bad behavior can often be attributed to a few simple things:
>
> - The compilers scanned the entire file before starting in on code
> generation, rather than scanning a function, doing code generation,
> scanning another function, doing code generation, etc. Because the
> input was big, the machines often ran out of swap.


This is a harder problem than might be imagined. Compiler has to look at
all the functions before generating any code because of the possibility
that routines might be inlined, right? Perhaps this could be avoided
using clever/annoying declarations before any uses of an inlined routine.
On the other hand, performing separate passes to lower memory requirements
is a well-known technique and should probably be used in this case.


> - Inlining parsed the functions but did not do any nested inlining
> ``up front''. So if A is inlined and contains inlined function B
> that contains inlined function C, then each place A is used the
> compiler goes back and computes again that B and C are inlined in
> A. The 7,000-line program makes extensive use of nested small
> inline functions. Thus it is slow to compile with many compilers.


A possible excuse for this behaviour is that the compiler didn't always
inline B and C into A; that is, it looked at the context of each call
before performing any inlining. In general, I'd say this is a smart move;
but again it sounds poorly engineered.


-----


A year or two ago, we had a nice argument/discussion about the (de)merits
of inlining. This case serves to illustrate one of my complaints -- gross
compile times. We might also use this case to examine my other complaint
-- small payoffs. Has the author measured how much performance he gets
from all his inlining? How much performance improvement would justify (to
him) such extended compilation times?


Preston Briggs
--

Return to the comp.compilers page.
Search the comp.compilers archives again.