[GHC] #9718: Avoid TidyPgm predicting what CorePrep will do

[GHC]

#9718: Avoid TidyPgm predicting what CorePrep will do
-------------------------------------+-------------------------------------
       Reporter:  simonpj            |                   Owner:
           Type:  bug                |                  Status:  new
       Priority:  normal             |               Milestone:
      Component:  Compiler           |                 Version:  7.8.3
       Keywords:                     |        Operating System:
   Architecture:  Unknown/Multiple   |  Unknown/Multiple
     Difficulty:  Unknown            |         Type of failure:
     Blocked By:                     |  None/Unknown
Related Tickets:                     |               Test Case:
                                     |                Blocking:
                                     |  Differential Revisions:
-------------------------------------+-------------------------------------
 At the moment the `TidyPgm` pass is forced to predict, accurately but
 unpleasantly, some aspects of what `CorePrep` and `Core2Stg` will do.
 Reason:

  * Each `Id` in the interface file records (among other things) the
 '''arity''' of the `Id`, and whether it has '''CAF references'''

  * We really only know these two things for sure after `CorePrep`.  The
 conversion from Core to STG makes no structural changes.

  * However the result of `TidyPgm` (which preceded `CorePrep`) is used to
 generate the interface file.  So it has to predict the arity and CAF-ref
 status of each `Id`.

  * This is not good.  It restricts what `CorePrep` can do (notably, it
 must not change the arity of a top-level `Id`), and it leads to unsavoury
 code (e.g. look at the call to `CorePrep.cvtLitInteger` in
 `TidyPgm.cafRefsL`.  It's also dangerous: an inconsistency could lead to a
 crash.

 This is a long-standing problem.  My current thought for how to unravel it
 is this:
  * `TidyPgm` does not attach arity or CAF-ref info.
  * Instead, run `CorePrep` after `TidyPgm`, and generate accurate arity
 and CAF-ref info
  * Then use that auxiliary mapping during the conversion from tidied
 program to `ModIface`.

 I don't think this would be hard.  It would mean that the tidied program
 and the core-prep'd program would have to exist in memory at the same
 time.  An alternative would be to generate the `ModIface` from the tidied
 program ''sans'' arity and CAF-ref info, and then, after `CorePrep` run
 over it to add arity and CAF-ref info.  (You'd have to do this before
 generating the fingerprints.)  The advantage of this is that the
 `ModIface` can be a lot smaller than the code for the entire module.

 A long-standing wart which needs some careful attention.

 Simon

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