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.''
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users