[GHC] #15445: SPECIALIZE one of two identical functions does not fire well

[GHC]

#15445: SPECIALIZE one of two identical functions does not fire well
-------------------------------------+-------------------------------------
        Reporter:  nobrakal          |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.6.1
       Component:  Compiler          |              Version:  8.4.3
      Resolution:                    |             Keywords:
Operating System:  Linux             |         Architecture:  x86_64
                                     |  (amd64)
 Type of failure:  None/Unknown      |            Test Case:
                                     |  simplCore/should_compile/T15445
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by Simon Peyton Jones <simonpj@…>):

 In [changeset:"3addf72a6f40747cff213653382eb4476bdb53da/ghc" 3addf72/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="3addf72a6f40747cff213653382eb4476bdb53da"
 Preserve specialisations despite CSE

 Trac #15445 showed that, as a result of CSE, a function with an
 automatically generated specialisation RULE could be inlined
 before the RULE had a chance to fire.

 This patch attaches a NOINLINE[2] activation to the Id, during
 CSE, to stop this happening.

 See Note [Delay inlining after CSE]

 ---- Historical note ---

 This patch is simpler and more direct than an earlier
 version:

   commit 2110738b280543698407924a16ac92b6d804dc36
   Author: Simon Peyton Jones <simonpj at microsoft.com>
   Date:   Mon Jul 30 13:43:56 2018 +0100

   Don't inline functions with RULES too early

 We had to revert this patch because it made GHC itself slower.

 Why? It delayed inlining of /all/ functions with RULES, and that was
 very bad in TcFlatten.flatten_ty_con_app

 * It delayed inlining of liftM
 * That delayed the unravelling of the recursion in some dictionary
   bindings.
 * That delayed some eta expansion, leaving
      flatten_ty_con_app = \x y. let <stuff> in \z. blah
 * That allowed the float-out pass to put sguff between
   the \y and \z.
 * And that permanently stopped eta expasion of the function,
   even once <stuff> was simplified.

 -- End of historical note ---
 }}}

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