[GHC] #9660: unnecessary indirect jump when returning a case scrutinee

[GHC]

#9660: unnecessary indirect jump when returning a case scrutinee
-------------------------------------+-------------------------------------
              Reporter:  rwbarton    |            Owner:
                  Type:  bug         |           Status:  new
              Priority:  normal      |        Milestone:
             Component:  Compiler    |          Version:  7.8.3
  (CodeGen)                          |         Keywords:
            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 rwbarton):

 Replying to [comment:6 schyler]:
 > Could you show the core difference (for us who don't really understand
 the original ticket that well)?

 There is no difference at the Core level. In either case the core is
 {{{
 Test.f =
   \ (x_arU :: GHC.Types.Int) ->
     case x_arU of wild_a10j { GHC.Types.I# x1_a10l ->
     case GHC.Prim.tagToEnum# @ GHC.Types.Bool (GHC.Prim.<# x1_a10l 0)
     of _ [Occ=Dead] {
       GHC.Types.False -> GHC.Types.I# (GHC.Prim.+# x1_a10l 1);
       GHC.Types.True -> wild_a10j
     }
     }
 }}}

 The difference is that in the generated Cmm, we don't re-enter `wild_a10j`
 in the True case, since we know it has already been reduced to WHNF by the
 first `case`.

 > Also, if you dump and attach the ASM I'd be happy to sift through and
 find the problem.

 I don't have a copy of the instances I was looking at any more, but in one
 case the change seemed to affect the unique names chosen, which apparently
 led to laying out functions in a different order... annoying for trying to
 diff.

 My main question here is whether it's actually a good idea to use an
 error/panic in the LambdaFormInfo, or is it better to add a new
 constructor. I sort of like the error in that if something goes wrong,
 it's more likely to do so at compile time than at run time; but it's also
 a bit ugly.

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