[GHC] #12622: Unboxed static pointers lead to missing SPT entries
GHC
ghc-devs at haskell.org
Mon Nov 21 18:23:41 UTC 2016
#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
More information about the ghc-tickets
mailing list