#12689: DataCon wrappers get in the way of rules -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): We might want to look at two separate cases: 1. The LHS mentions a data con (wrapper) unsaturated, (`fT` above). 2. The LHS mentions a data con (wrapper) saturated, (`gT` above). In the first case, I think we should simply disable the warning. Because the wrapper is unsaturated, it will not have been inlined in the code. Unsaturation is as good as `NOINLINE`, isn’t it? Only in the latter case it matters that, as you write

after inlining we get a mess of unboxing etc Is really all hope lost that we can match the mess? My gut feeling is that it is more promising to not work against the inliner and simplifier, and rather let it do its jobs (both on the LHS and the code), and try hard to make the matcher smart enough to match the mess.

-- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12689#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12689: DataCon wrappers get in the way of rules -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"f8d2c205e04bcb83d39ccbede4c2a6279f702a6b/ghc" f8d2c205/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f8d2c205e04bcb83d39ccbede4c2a6279f702a6b" Add a broken test case for #12689 A rule with a phase specification trying to match on a constructor with a wrapper will fail to match, as the wrapper will be inlined by then. The fact that it works in the other case is also mostly by accident. (Split into two test cases so that regressions with regard what works so far are caught.) }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12689#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12689: DataCon wrappers get in the way of rules -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Here is an idea that came out of what Iavor said (or at least how I understood him). There are still open questions, but I do like the general approach: Consider a rule (which I write with the wrapper name already, as that is what we desugar to these days) {{{ RULE forall a b. foo ($WMkCon a b) = bar a b }}} and a wrapper {{{ $WMkCon a b = case a of (a1,a2) -> MkCon a1 a2 b }}} We don’t want cases on the LHS of the rule, so we do not just want to inline MkCon into the LHS. But what if we move it to the right hand side, and write the rule like that: {{{ RULE forall a1 a2 b. foo (MkCon a1 a2 b) = let a = (a1,a2) in bar a b }}} The rule is nice because the LHS is a normal form (with regard to the simplifier and the rewrite rules). The necessary transformations could be stored with the unfolding information of `$WMkCon`. At least for a strict `foo`, things might work out. We’d get: {{{ case some expr of (a1,a2) -> … foo (MkCon a1 a2 someB) … → case some expr of (a1,a2) -> … (let a = (a1,a2) in bar a someB) … -- rule fires → case some expr of (a1,a2) -> … bar (a1,a2) a someB … -- inlining }}} and further cleanup may happen due to CSE. Unfortunately it does not work as immediately if `foo` is not strict, as the `case` does not get floated out of the way, and we need to match an expression like {{{ foo (case some expr of (a,b) -> MkCon a1 a2 someB) }}} and it would not be sound if the matcher would simply float the case out of the way. So this idea requires more thought. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12689#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler