[GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial

[GHC]

#11158: Combine exprIsTrivial and cpe_ExprIsTrivial
-------------------------------------+-------------------------------------
        Reporter:  simonpj           |                Owner:
            Type:  task              |               Status:  infoneeded
        Priority:  highest           |            Milestone:  8.2.1
       Component:  Compiler          |              Version:  7.10.2
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D1656
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 It's worth reading `Note [CafInfo and floating]` in `CorePrep`.

 Here's what I don't understand:

 1. I think that local bindings (which may get floated) have by-default a
 `MayHaveCafRefs` flag.  Worth checking.

 2. I don't understand why a top-level binding
 {{{
 sat1 = Nothing
 }}}
   (with a `MayHaveCafRefs` flag) gives rise to a `Nothing_closure` in the
 SRT of the binding mentioning `sat`, whereas
 {{{
 sat2 = GHC.Tuple.()
 }}}
   (also with a `MayHaveCafRefs` flag) gives rise to a `sat2_closure` entry
 in he SRT.  Why are the two treated differently?

 3. In the binding
 {{{
 main = return @ IO GHC.Base.$fMonadIO @ () GHC.Tuple.()
 }}}
   I don't understand why we ANF-ise the `GHC.Tuple.()` argument.  It's
 already atomic; no need to create a binding for it.  Does the same happen
 for `Nothing`?

   '''Simon''', do you have any ideas there?  E.g. maybe data constructor
 closures are in static space and can't get marked by the CAF traversal or
 something?  It'd be good to document it.

 4. I don't understand why having those entries in the SRT would cause a
 crash.

 Finally, although it woudl be great to understand these things, the Real
 Solution is #9718, which I have been longing to get done for literally
 years.   I really don't think it's hard; we just need to be a bit careful
 about memory usage.

 I'd rather fix #9718 than burn cycles doing very careful jiggery-pokery
 with `CorePrep` and floating.  Fixing #9718 fixes the problem at source,
 rather than perpetuating it.

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