[GHC] #9291: Don't reconstruct sum types if the type subtly changes

[GHC]

#9291: Don't reconstruct sum types if the type subtly changes
-------------------------------------+-------------------------------------
        Reporter:  schyler           |                Owner:
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  7.8.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 nomeata):

 > Is this related with typed-ness of the IR?

 Yes! The type system of Core ensures that we cannot get the ST stuff wrong
 (to some extent. It still requires us to also not inline `runRW#`, for
 example).

 >  I think if we do some of the transformations we do during `coreToStg`
 we would have the same problem in Core too.

 You mean inlining `runRW#`? Right, we should not do that. I tried that
 once, and it broke :-)

 >  I'm wondering if a solution could be as simple as treating state tokens
 as different from each other when comparing expressions...

 Sure, such reasoning will be required. Is the only such case?

 Also, in this case, CSE’ing the state token isn’t the problem per se (the
 state token is a zero-width value, so operationally, they are all equal).
 The real problem is CSE’ing `newMutRef#` which has a side-effect. So maybe
 only CSE’ing constructor applications is a safer start.

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