Re: [GHC] #14564: CAF isn't floated

8 Dec 2017

      #14564: CAF isn't floated
-------------------------------------+-------------------------------------
        Reporter:  neil.mayhew       |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.2.2
      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 simonpj):

 I took a look.  Here's what is happening.  Just before the full laziness
 pass (which does the floating) we have
 {{{
 parseFilename
   = \ (fn_a35P :: String) ->
       case Text.Regex.Base.Context.$fRegexContextabAllTextMatches9
              @ [Char]
              (Text.Regex.TDFA.String.$fRegexLikeRegex[]_go
                 Text.Regex.TDFA.String.$fRegexContextRegex[][]3
                 fn_a35P
                 (Text.Regex.TDFA.NewDFA.Engine.execMatch_$sexecMatch3
                    (case Text.Regex.TDFA.String.$w$cmakeRegexOpts
 Text.Regex.TDFA.Common.$fRegexOptionsRegexCompOptionExecOption_$cdefaultCompOpt
 Text.Regex.TDFA.Common.$fRegexOptionsRegexCompOptionExecOption_$cblankExecOpt
                            (GHC.Base.build
                               @ Char
                               (\ (@ b_a5BF) ->
                                  GHC.CString.unpackFoldrCString#
                                    @ b_a5BF
 "^\\./duplicity-(full|inc|new)(-signatures)?\\.([0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]T[0-9][0-9][0-9][0-9][0-9][0-9]Z)\\."#))
                     of
                     { (# ww1, ww2, ww3, ww4, ww5, ww6, ww7, ww8, ww9, ww10
 #) ->
                     Text.Regex.TDFA.Common.Regex ww1 ww2 ww3 ww4 ww5 ww6
 ww7 ww8 ww9 ww10
                     })
                    Text.Regex.TDFA.String.$fRegexContextRegex[][]3
                    Text.Regex.TDFA.String.$fRegexContextRegex[][]2
                    fn_a35P))
       of { ... }
 }}}
 Somme inlining has happened, but the constant expression we want to float
 to top level is the
 argument to `$sexecMatch3`, namely
 {{{
   (case Text.Regex.TDFA.String.$w$cmakeRegexOpts
 Text.Regex.TDFA.Common.$fRegexOptionsRegexCompOptionExecOption_$cdefaultCompOpt
 Text.Regex.TDFA.Common.$fRegexOptionsRegexCompOptionExecOption_$cblankExecOpt
           (GHC.Base.build
              @ Char
              (\ (@ b_a5BF) ->
                 GHC.CString.unpackFoldrCString#
                   @ b_a5BF "blah blah""#))
    of
    { (# ww1, ww2, ww3, ww4, ww5, ww6, ww7, ww8, ww9, ww10 #) ->
    Text.Regex.TDFA.Common.Regex ww1 ww2 ww3 ww4 ww5 ww6 ww7 ww8 ww9 ww10
    })
 }}}
 Alas, if you look at `SetLevels.lvlMFE`, there is a special case for
 `case` expressions, discussed in `Note [Case MFEs]`.  And, since
 `$sexecMatch3` is strict, the special case fires, and the case-expression
 is not floated.

 Now `Note [Case MFEs]` claims that we'll take a sparate decision for the
 scrutinee (which is where all the work is).  But in this case the
 scrutinee is an unboxed tuple, which also can't float to top level.  So we
 can't flat that either, and we just lose, as Neil discovered.

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