Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!world!iecc!compilers-sender From: pardo@june.cs.washington.edu (David Keppel) Newsgroups: comp.compilers Subject: Re: the Evil Effects of Inlining Keywords: optimize, design Message-ID: <1991May3.222452.16446@beaver.cs.washington.edu> Date: 3 May 91 22:24:52 GMT References: <1991May1.035622.25021@daffy.cs.wisc.edu> <1991May2.180508.17100@rice.edu> Sender: compilers-sender@iecc.cambridge.ma.us Reply-To: pardo@june.cs.washington.edu (David Keppel) Organization: Computer Science & Engineering, U. of Washington, Seattle Lines: 22 Approved: compilers@iecc.cambridge.ma.us >Preston Briggs writes: >>[Some reasons why you might not want to inline] > REGISTER PRESSURE: > Call sites are natural places to spill lots of registers. > Register allocators are rarely able to achieve the same efficiency. daniel@quilty.Stanford.EDU (Daniel Weise) writes: >[So we have to make better register allocators.] Stronger than that: if the call site is the right place to save/restore registers, then save and restore registers at the call site, around the inlined function. Then delete any redundant (useless) saves and restores. On the basis of register pressure, you couldn't possibly do worse than a function call. You might still suffer all the other side effects (code growth, etc.). ;-D on ( It's all caching ) Pardo -- Send compilers articles to compilers@iecc.cambridge.ma.us or {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.