#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