- The increase in binary sizes (at least for the atom benchmark) is coming from a handful of modules in ghc-prim and base - GHC/Types.o has increased by about 5K. It's now the home of the SrcLoc and CallStack types, which together define 7-8 record selectors, so I
#10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by gridaphobe): Just copying some notes from our discussion on phabricator for easy reference: gridaphobe: think this may not be too surprising.
- Control/Applicative.o, Data/Either.o, Data/Foldable.o, and a few others in base have increased in by 2-5K each. Every one of these modules contains at least one CallStack in the Core. - The other modules I've looked at that have not increased in size do not have a CallStack, so it seems pretty clear that the increase *is* due to the CallStack. - Finally, I think you're correct that the CallStacks are being inlined sometimes, because I found a CallStack referencing GHC.Base in Data.Foldable.
I’m not quite sure what the best way is to prevent the sharing. Maybe
nomeata: the type checker, which produces the CallStack values, can be told to add the (core equivalent) of a NOINLINE pragma to them? --- I agree that CallStacks should not be inlined. Is there a core equivalent of a NOINLINE pragma? If so, it ought the be straightforward to have the desugarer attach it. Also, is there any extra cost to lifting all of the int and string components of a `SrcLoc` to top-level binders (which seems similarly pointless)? Or does it just clutter the Core output? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10844#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler