[GHC] #10012: Cheap-to-compute values aren't pushed into case branches inducing unnecessary register pressure

[GHC]

#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]:
 > In comment:4 simon (or ben?) says “duplicating work”, but it seems that
 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?

 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).

 > But what is so special about this `case` that makes this a worthwhile
 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