Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uunet!world!iecc!compilers-sender From: mac@eleazar.dartmouth.edu (Alex Colvin) Newsgroups: comp.compilers Subject: Re: the Evil Effects of Inlining Keywords: optimize, design Message-ID: <1991May3.205613.6419@dartvax.dartmouth.edu> Date: 3 May 91 20:56:13 GMT References: <1991May1.035622.25021@daffy.cs.wisc.edu> <1991May2.180508.17100@rice.edu> Sender: compilers-sender@iecc.cambridge.ma.us Reply-To: mac@eleazar.dartmouth.edu (Alex Colvin) Organization: Spurious Interrupts Lines: 15 Approved: compilers@iecc.cambridge.ma.us As others have pointed out, an environment (like C++) that supports inlining encourages the use of procedures that the programmer would manually inline in the absence of such support. Trivial inlined procedures give you access control to various module data, e.g. read- or increment-only access. Another thing inlining gives you is better flow analysis with a way to fold constants into procedures. This makes optimizations such as { if (false) S1 else S2 } -> S2 more useful. In this case, you expect the body to expand to different code in each instance. -- Send compilers articles to compilers@iecc.cambridge.ma.us or {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.