#12622: Unboxed static pointers lead to missing SPT entries -------------------------------------+------------------------------------- Reporter: mboes | Owner: | facundo.dominguez Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 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:D2709 Wiki Page: | Phab:D2720 -------------------------------------+------------------------------------- Comment (by facundo.dominguez):
I'm betting that if we had a top-level binding x = makeStatic e then it would never get inlined anyway.
Indeed, I would hope GHC has no incentive to inline it.
You say that FloatOut would have go treat makeStatic specially, when not currently treat StaticPtr specially. Why?
The SetLevels pass checks if a soon-to-be new top-level binding is a static pointer to determine what kind of Id to produce for the new binding (bindings of StaticPtrs need to be of //exported// kind). But so far the SetLevels pass decides on its own that the static pointer needs to be floated, because, I presume, most or all data constructor applications are treated like that. If we want SetLevels to float `makeStatic e`, we probably will have to modify the decision procedure to treat `makeStatic e` unlike other function applications and always float it. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12622#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler