Hacker News Reader

Comment by bjoli | Hacker News Reader

The hardest thing I ever wrote was an inliner for a language I made myself.

You'd think it is a simple problem, but soon you will have a rabid animal on a leash and you will be struggling to restrain it.

I gave the source to a friend who modified it a bit and commited it to a language that was mentioned a couple of times on HN in the early days. It has since been replaced, but was used for a good 5 years.

View on HN

Can you expand on some of the problems?

I was going to write an inliner for a Lisp I was working on for a couple years. Emacs seems to have a decent one. But I know there are tricky corner cases.

Writing a simple inliner isn't too bad, writing a good one is hard. Let's pretend you just "copy/paste" the code into place, there's the question of deciding when/if to copy/paste the code in -- what heuristic do you use. Now there's constant propagation, possibly more doing dead code (from constant propagation), dependency reanalysis (because you've changed the basic block, possibly adding more basic blocks). There are reasons the resultant code could even be less efficient (register pressure for locals for the inline code comes to mind), and there's i-cache complexities that come from blowing up your code size.

Inlining is really hard.

nappy-doo answered the question very well. One thing that should be mentioned is that a bad inliner actually removes information that might be useful for future optimisations.

Reading the inliners of languages like chez scheme or ghc is enough to give me a hardon.

Reply on news.ycombinator.com