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

[GHC]

#9718: Avoid TidyPgm predicting what CorePrep will do
-------------------------------------+-------------------------------------
        Reporter:  simonpj           |                Owner:
            Type:  task              |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  7.8.3
      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:                    |
-------------------------------------+-------------------------------------
Description changed by simonpj:

@@ -31,5 +31,12 @@
- 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.
+ 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.
+
+ Another alternative would be to ensure that after `CoreTidy` we treat each
+ top-level binding one at a time, and pump them right down the pipeline
+ individually, all the way through code generation.  That way we would
+ avoid creating the STG, or Cmm, for the entire program all at once.

New description:

 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.

 Another alternative would be to ensure that after `CoreTidy` we treat each
 top-level binding one at a time, and pump them right down the pipeline
 individually, all the way through code generation.  That way we would
 avoid creating the STG, or Cmm, for the entire program all at once.

 A long-standing wart which needs some careful attention.

 Simon

--

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