In comment:4 simon (or ben?) says “duplicating work”, but it seems that
#10012: Cheap-to-compute values aren't pushed into case branches inducing unnecessary register pressure -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Replying to [comment:7 nomeata]: the question at hand is not about loss of sharing, but rather code size, right? Floating a let binding into the branches of a case does not duplicate any work, only code.
Correct, the primary concern is code size.
A `{-# INLINE_THROUGH #-}` pragma seems to be a bit unspecific. Do we really want the compiler to inline through everything, no matter how large? Or should this just shift the heuristics a bit?
But what is so special about this `case` that makes this a worthwhile
Indeed it is intentionally unspecific because I haven't yet found enough other potential use-cases for such a pragma to know what semantics would make the most sense. My first inclination was to essentially render the `case` invisible to the simplifier and float freely into the branches but simply shifting the float-in heuristics would also be a reasonable option (albeit perhaps a bit harder to reason about). thing here, and not in other cases (sic)? Maybe the heuristics can be improved in general?
Unfortunately I haven't been able to pin this down very clearly beyond it occurring in an "inner loop".
It seems to be more a general question of whether the user wants more speed or smaller code.
Right, but not all case analyses are created equal: examples like this one which occur in an inner loop deserve more inlining than others, yet I'm not sure GHC is in a position to be able to discern this. This is why I proposed simply providing a tool for nudging the compiler in the right direction. Clearly following this approach of adding source-level knobs to guide arbitrary simplifier heuristics to its logical conclusion is a path to madness; unfortunately I don't see a more general way to robustly address the issue at hand. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10012#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler