#9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): * Yes, I think we should take the arity and CAFness from the STG code, not ''just after we generate it'', but rather ''just before we code-gen it'' , which is the moment of truth. * Rather than use the `IfaceIdInfo` for these two fields, I think we could make them two fixed fields of each top-level Id binding in a `ModIface`. Every Id has CAF-ness and arity. * The final arity is really the ''representation'' arity, after unarisation of unboxed tuples etc. I think we should probably treat that as a separate matter to the "arity" recorded by the Simplifier. The latter really can be passed on by CoreTidy, exactly as now. The former determines calling convention etc; it's a code-gen thing. We currently fudge this issue: see `idRepArity`. * Fingerprints will indeed change; but they are in any case calculated separately; see `addFingerprints`. So we probably want to defer that step too. * For now, I'd be inclined to simply hold onto the partly-complete `ModIface` until codegen; then add info from the just-before-codegen STG code; and construct a final `ModIface`. If that gives rise to residency issues we can decide what to do then. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9718#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler