[GHC] #15698: SingleEntry update flag for Stg bindings is not used

[GHC]

#15698: SingleEntry update flag for Stg bindings is not used
-------------------------------------+-------------------------------------
           Reporter:  osa1           |             Owner:  (none)
               Type:  task           |            Status:  new
           Priority:  lowest         |         Milestone:  8.6.1
          Component:  Compiler       |           Version:  8.6.1
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 I was looking at code generation for bindings with different update flags.
 Update flag type is defined as:

 {{{
 data UpdateFlag = ReEntrant | Updatable | SingleEntry
 }}}

 I realized that we don't care about the difference between `ReEntrant` and
 `SingleEntry`, we only care about whether a binding is updatable or not,
 which is defined as

 {{{
 isUpdatable :: UpdateFlag -> Bool
 isUpdatable ReEntrant   = False
 isUpdatable SingleEntry = False
 isUpdatable Updatable   = True
 }}}

 So we could remove `SingleEntry` and replace all uses of it with
 `ReEntrant` and everything would work the same.

 This raises the question of whether we're missing an optimisation in the
 code generator. Looking at code generation differences of updatable and
 non-updatable bindings, it seems like for a thunk (a binding with no
 arguments) we generate a thunk header and push an update frame regardless
 of the update flag. As far as I can see, update flag is only used when
 generating AP and selector thunks (we don't generate AP or selector thunks
 if the binding is not updatable).


 My question is: it seems to me that if a thunk is single entry then we
 should be able to give it a non-thunk type (maybe FUN?) and avoid pushing
 an update frame in `closureCodeBody`. Am I missing anything or is this
 possible? Is this worth trying?

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