#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