Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!world!iecc!compilers-sender From: mjs@hpfcso.fc.hp.com (Marc Sabatella) Newsgroups: comp.compilers Subject: Re: Is inlining evil? Keywords: optimize, design Message-ID: <1991May08.175206.19845@iecc.cambridge.ma.us> Date: 8 May 91 17:17:59 GMT References: <9105031304.AA00625@slave.vlsivie.tuwien.ac.at> Sender: compilers-sender@iecc.cambridge.ma.us Reply-To: Marc Sabatella Organization: Compilers Central Lines: 25 Approved: compilers@iecc.cambridge.ma.us Preston makes some good points about "naive inlining". But there is no particular reason inlining need be so naive. The HP-UX C and Fortran compilers for 680x0 do inlining under +O3, and the programmer is offered considerable control over the inlining process via command line options and compiler directives. The default for +O3 is to inline any function that is under a certain size, but that measurement is made before any of its own calls are inlined, so you can easily end up with a sort of combinatorial explosion. However, you can set the size limit, also you can (via directive) turn on or off inlining for a particular function, and you can even turn off the inlining at the point of call, so that some calls to a given function are inlined and others aren't. You can also control whether standalone code for the function should also be emitted (to allow external calls). My own experience on a small but very "real" program is that after spending a day or two experimenting, figuring out which calls to inline and which not to, I ended up with a program that was 10% larger and 10% faster, and I considered the whole deal to be a fair tradeoff of my time, run time, and space. -------------- Marc Sabatella (marc@hpmonk.fc.hp.com) -- Send compilers articles to compilers@iecc.cambridge.ma.us or {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.