[GHC] #13340: Core top-level bindings no longer deduplicated

[GHC]

#13340: Core top-level bindings no longer deduplicated
-------------------------------------+-------------------------------------
        Reporter:  rwbarton          |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  highest           |            Milestone:  8.2.1
       Component:  Compiler          |              Version:  8.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 I realised the following two things.

 * If we wanted to distinguish between stable-unfoldings created by user-
 specified INLINE pragmas, from those created by `WorkWrap` (see `Note
 [Don't w/w inline small non-loop-breaker things] there), we can do so.
 The former has `inl_spec = Inline` in its `InlinePragma`; the latter has
 `inl_spec = EmptyInlineSpec`.

 * But re-reading the note
 {{{
 Note [CSE for stable unfoldings]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Consider
    {-# Unf = Stable (\pq. build blah) #-}
    foo = x

 Here 'foo' has a stable unfolding, but its (optimised) RHS is trivial.
 (Turns out that this actually happens for the enumFromTo method of
 the Integer instance of Enum in GHC.Enum.)  Then we obviously do NOT
 want to extend the substitution with (foo->x)!   See similar
 SimplUtils Note [Stable unfoldings and postInlineUnconditionally].

 Nor do we want to change the reverse mapping. Suppose we have

    {-# Unf = Stable (\pq. build blah) #-}
    foo = <expr>
    bar = <expr>

 There could conceivably be merit in rewriting the RHS of bar:
    bar = foo
 but now bar's inlining behaviour will change, and importing
 modules might see that.  So it seems dodgy and we don't do it.
 }}}
   suppose both `foo` and `bar` have a stable-unfolding, and they are
 identical. That's exactly the situation in the examples above.  Then it'd
 be fine to replace `bar` by `foo`.

 I think we should try the second of these.  Not hard I think.

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