[Haskell] Expecting more inlining for bit shifting

[Simon Peyton-Jones]

| 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
that
| can be precomputed, and then tries to determine if it is worth making
a
| specialized function with that case eliminated.  Or possibly having
each
| 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"
http://research.microsoft.com/%7Esimonpj/Papers/inlining/index.htm

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
taught
| in my undergraduate CS program (but perhaps I wasn't) that one ought
not
| to make these sorts of trivial hand optimisations, because compilers
are
| smart enough to figure out these sorts of things by themselves, and
they
| know more about that target platform that you do.  In particular the
| propaganda about side-effect-free functional languages was a promise
that
| they would use the strong types and side-effect-freeness to do all
sorts
| 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.

Simon

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.