[GHC] #9688: Improve the interaction between CSE and the join point transformation

[GHC]

#9688: Improve the interaction between CSE and the join point transformation
-------------------------------------+-------------------------------------
              Reporter:  dfeuer      |            Owner:
                  Type:  feature     |           Status:  new
  request                            |        Milestone:
              Priority:  normal      |          Version:  7.9
             Component:  Compiler    |         Keywords:  CSE
            Resolution:              |     Architecture:  Unknown/Multiple
      Operating System:              |       Difficulty:  Unknown
  Unknown/Multiple                   |       Blocked By:
       Type of failure:  Runtime     |  Related Tickets:
  performance bug                    |
             Test Case:              |
              Blocking:              |
Differential Revisions:              |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 Indeed!   It looks like a classic code-specialisation question to me.  In
 `digitToIntMaybe` you use some code `isHexDigit` that just happens to use
 the same tests as the RHS, `digitToInt`. Moreover there are three ways for
 `isHexDigit` to succeed.  If you duplicate the RHS into those three
 outcomes you'll get the result you want; this amounts to inlining
 `$j_s2BC`.  But that entails code duplication -- and might gain nothing
 whatsoever.

 Or, to put it another way, if the user wrote the above `Core`, complete
 with the local function `$j_s2BC`, would you expect it to be optimised?

 It would be cool if so.  But I don't yet see how to achieve that at
 reasonable cost.

 To put it another way, if you wrote this in C:
 {{{
 if blah then x = e1 else x = e2
 if similar-blah then s1 else s2
 }}}
 you'd usually expect to test `blah`, assign to `x`, and then test
 `similar-blah` and do `s1` or `s2`.  But it might be better to duplicate
 (i.e. specialise) the first `if` into the branches:
 {{{
 if similar-blah then {
   if blah then x=e1 else x=e2
   s1
 } else {
   if blah then x=e1 else x=e2
   s2
 }
 }}}
 and now the inner `if` might be optimised away entirely.

 These are not simple choices. By representing them as simple inlining
 choices ("shall I inline `$j_s2Bc`?") GHC piggy backs on a lot of careful
 heuristics for inlining.  But, I agree, it does not always work well.

 I have taken time to explain here, in the hope that someone can do better!

 Simon

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9688#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler