Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!mintaka!spdcc!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: <1991May5.224015.21588@beaver.cs.washington.edu> Date: 5 May 91 22:40:15 GMT References: <1991May2.180508.17100@rice.edu> <1991May3.222452.16446@beaver.cs.washington.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: 34 Approved: compilers@iecc.cambridge.ma.us Ooops. I wrote something very unclear: >Preston Briggs writes: >>[Register allocators aren't as smart as bind save/restore at >> the call site.] pardo@june.cs.washington.edu (David Keppel) writes: >[Technique...] 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.). Gee, it sounds like I'm saying that a function call is the worst of all possible worlds, when I was talking about avoiding the function call. What I *meant* to say (I really did re-read it, but it made sense at the time) was that if you: * Do register saves and restores in the caller like you were doing a function call * Do register allocation in the callee like it was a real function * Inline the function then you can: * Use the same register allocation strategy and get no worse register allocation * Remove redundant register saves and restores * Remove redundant branches Hopefully it make sense this time. ;-D on ( Confusion reigns supreme ) Pardo -- Send compilers articles to compilers@iecc.cambridge.ma.us or {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.