[GHC] #9279: Local wrapper function remains in final program; result = extra closure allocation

[GHC]

#9279: Local wrapper function remains in final program; result = extra closure
allocation
-------------------------------------+-------------------------------------
        Reporter:  simonmar          |                Owner:  simonpj
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  7.8.2
      Resolution:                    |             Keywords:  LateLamLift
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Runtime           |  Unknown/Multiple
  performance bug                    |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 There are two things going on in this ticket

 1. Should we inline wrappers late in the pipeline? See comment:4

 2. Can we do a better job for "absent" arguments of unlifted types.

 I'll concentrate on (2) in this comment; but we should not lose sight of
 (1).  In fact it might be better to make (2) a new ticket and leave this
 one for (1) -- or vice versa.

 For a long time, the worker/wrapper splitter has given up on absent
 arguments of certain unlifted types: see `Literal.absentLiteralOf` and
 `Note [Absent errors]` in `WwLib`.  This is very annoying because it means
 that we get left with functions that take a bunch of arguments they do not
 use, as in this ticket.

 For lifted types T we build an absent value as a thunk of form
 {{{
   aBSENT_ERROR_ID @T "Used absent value"
 }}}
 This does two things
 A.  It gives us something, of the right type, to use in place of the value
     we aren't passing any more.
 B.  It gives an extra sanity check: if that value is ever used (a compiler
     bug) we'll get a runtime error message.

 For unlifted types we don't have thunks, so we can't do this.  As you can
 see in `absentLiteralOf`, for some types we just make up a silly value:
 e.g. for `Char#` we use `'x#'`; for `Int#` we use `0#`.

 Note, however that

 * Substituting a particular value serves purpose (A) but not purpose
   (B).  A compiler bug would go undetected.  This is sad: e.g. #11126
   is a real bug that was detected by (B).  But I see no way out.

 * It doesn't work for `Array#`, `MutVar#`, `TVar#` etc because we have
   no available literal values of those types.

 So Sebastian is suggesting that we add a new literal value -- call it
 a '''rubbish value''' -- which can work for any (unlifted type),
 extending `Literal` something like this
 {{{
 data Literal = ...
   | RubbishLit Type
 }}}
 We need to store the type so we can still do `literalType`.

 Now
 * Maybe we could get rid of `MachNullAddr` in favour of this new literal.

 * I think -- but I am not sure -- that this literal should never occur
   in code generation. For example, we should never pass a rubbish value
   to a function. Before then dead-code elimination should have got rid
   of it  I'm not 100% certain, but if this was true, it'd be a great
   sanity check.

 * Yes, `Literal` has `Eq` and `Ord` -- but I'm not sure why.  Try removing
   them and seeing what happens!  (Generally I think it'd be better to
   define `eqLit` and `cmpLit` and cal them, rather than use `==` and `>`;
   so much easier to grep for!

   And in fact, we do have `eqType` and `cmpType`.

 * Do we need to spit out a `RubbishLit` in the `Binary` instance.
   This seems more likely, because perhaps these rubbish values can occur
   in unfoldings, which are serialised as their parse tree.  But
   the we can just serialise the `Type`.  It won't happen much.

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