[Haskell] Expecting more inlining for bit shifting

Simon Peyton-Jones simonpj at microsoft.com
Tue Oct 10 03:31:25 EDT 2006

| I would have imagined an optimisation step that only activates when a
| constructor is passed into a function to see if it produces a branch
| can be precomputed, and then tries to determine if it is worth making
| specialized function with that case eliminated.  Or possibly having
| function inspected to see if it has branches that could be eliminated
if a
| constructor was passed as an argument.

That's precisely what GHC does.  My explanation before was too brief,
sorry.  The algorithm is described in "Secrets of the GHC inliner"

But it still only makes a specialised copy if the function is "small
enough".  Obviously a great big function with a tiny specialisation
opportunity would be a poor candidate.  

| I must say I'm extremely disappointed with this.  I believe I was
| in my undergraduate CS program (but perhaps I wasn't) that one ought
| to make these sorts of trivial hand optimisations, because compilers
| smart enough to figure out these sorts of things by themselves, and
| know more about that target platform that you do.  In particular the
| propaganda about side-effect-free functional languages was a promise
| they would use the strong types and side-effect-freeness to do all
| of wonderful optimisations.

Well I think if you use -ddump-simpl you'll see a program that often
looks pretty different to the one you wrote.  I often have difficulty
figuring out just how GHC managed to transform the source program into
the optimised one.

Of course it's far from perfect!  Fortunately, GHC is an open-source
compiler, so the way lies open for anyone, including you, to improve the
inlining decisions.  I'm sure there are good opportunities there.


PS: you mention "knowing about the target platform".  That's one thing
that GHC is distinctly poor on.  It leaves all target-platform-specific
optimisations to the C compiler.

More information about the Glasgow-haskell-users mailing list