[GHC] #10844: CallStack should not be inlined
GHC
ghc-devs at haskell.org
Tue Oct 6 08:21:02 UTC 2015
#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
More information about the ghc-tickets
mailing list