[GHC] #7398: RULES don't apply to a newtype constructor
GHC
ghc-devs at haskell.org
Mon Jan 29 17:02:07 UTC 2018
#7398: RULES don't apply to a newtype constructor
-------------------------------------+-------------------------------------
Reporter: shachaf | Owner: (none)
Type: bug | Status: new
Priority: normal | Milestone: 8.6.1
Component: Compiler | Version: 7.6.1
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: Runtime | Unknown/Multiple
performance bug | Test Case:
Blocked By: | Blocking:
Related Tickets: #6082, #10418, | Differential Rev(s):
#13290 |
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by simonpj):
Currently, wen you have
{{{
{-# RULES "foo" forall x. f (g x) = h x #-}
}}}
we have to delay inlining `g` until the rule has had a decent
chance to fire. We currently do this manually, usually thus
{{{
{-# NOINLINE[1] f,g #-}
}}}
The obvious thing for newtypes (and indeed other data constructors, if
they have wrappers that unpack their arguments) is to delay inlining them.
Something like
{{{
newtype T a = MkT (Maybe a)
{-# NOINLINE[1] MkT #-}
}}}
We don't support that right now, but we could.
The alternative is to try to make the rule work ''after'' inlining `MkT`,
by being clever about casts. That might be possible.
But it doesn't work for data constructors like
{{{
data S = MkS {-# UNPACK #-} !Int
}}}
where the wrapper evaluates and unboxes the argument. After inlining, the
original `(f (MkS x))` turns into `f (case x ov I# y -> MkS y)`, which is
a lot harder to match.
So I think my suggestion, for now, is that we might want to allow users to
put a NOINLINE pragma on data constructors.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7398#comment:15>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list