[GHC] #13861: Take more advantage of STG representation invariance (follows up #9291)

[GHC]

#13861: Take more advantage of STG representation invariance (follows up #9291)
-------------------------------------+-------------------------------------
           Reporter:  heisenbug      |             Owner:  (none)
               Type:  feature        |            Status:  new
  request                            |
           Priority:  normal         |         Milestone:
          Component:  Compiler       |           Version:  8.0.2
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 Consider following `case` alternatives at the STG stage (i.e. untyped) :

 {{{#!hs
 case scrut of
   False -> []
   Just x -> Right x
   [] -> Nothing
 }}}

 The common theme of all these is that the scrutinee's memory layout and
 the result's memory layout coincide. So operationally no allocation needs
 to take place, and the whole `case` expression is simply a (strict)
 identity at the STG stage.

 I propose to add a small STG analysis to:
 * for each `case` alternative check whether the assigned tag between
 scrutinee and result matches, and if so
 * check whether both have the underlying memory layout and contents.

 If these conditions are met, the case alternative can be replaced with the
 identity. When all alternatives simplify to the identity (also considering
 the DEFAULT alternative), then the entire `case` expression reduces to a
 single identity DEFAULT alternative (i.e. all other alternatives in the
 `case` can be dropped).

 Many of the code examples in the join points paper
 (https://www.microsoft.com/en-us/research/wp-content/uploads/2016/11/join-
 points-pldi17.pdf) exhibit these optimisation opportunities.

 The already implemented suggestion in #9291 comes with the restriction
 that it only operates in the scope of the same type (see last comment
 there), but STG is untyped, so why not take advantage of this fact?

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