Okay, when I force inlining for shift, (and I even need to do it for shiftR!) then the code is inlined in C. However this isn't the behaviour I want. Ideally the inlining should only happen when/because the second argument of shift is constant and the system knows that it can evaluate the case analysis away and that makes the function small.
Am I being too naive on what to expect from my complier or is this reasonable?
It might be possible, but it sounds tricky. I guess it would have to go something like "try inlining this, run the simplifier, see if it got small enough, if not back out", which could waste a lot of work if it fails in lots of cases.
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. 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. However, it seems the truth of the matter is that an advanced compiler such as GHC cannot even optimise away the bounds checks occurring when shifting by a constant number of bits. -- Russell O'Connor http://r6.ca/ ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''