#10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe Type: task | Status: patch 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 Rev(s): Phab:D1259 -------------------------------------+------------------------------------- Comment (by simonpj): I think that (2) in comment:11 seems right to me. One path would be to adjust `FloatOut` so that * it picks up string literals; but remember that these "string literals" actually look like `(unpackCString# "foo"#)`. * (more invasively) it looks inside INLINE unfoldings, but in string- literal-only mode. That seems quite complicated. Another path is along the lines of your earlier patch: make the desugarer bind all string literals at top level in the first place. That way they'll be shared from birth. On the whole that sounds like an easier path to me. Particularly as the desugarer already uses a monadic function `mkStringExprFS` to make a new string literal, so you can make a desugarer-specific version of it which tosses a global binding into the monad. We'd need an extra bunch of monad-carried top-level bindings in the desugarer, but that is probably useful anyway. (It doesn't need to be string-specific.) Of course this would mean that, as Joachim points out (comment:10) that we wouldn't INLINE exactly what the programmer wrote: we'd share the string literal instead of copying it. But I think we should be able to guarantee that the effect is the same, provided we add a CONLIKE pragma to `unpackCSTring#`. (When doing this step, do some perf tests to check what happens.) This is all closely related to #8472, although it concerned unboxed string literals. There's a concrete proposal there, which would be good to execute on. In short, now we are focusing on string literals rather than call stacks, I agree that doing some extra work in the desugarer is probably the best path. BTW #5218 is in the same general area! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10844#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler