Re: [GHC] #7398: RULES don't apply to a newtype constructor

#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
participants (1)
-
GHC