#2598: Avoid excessive specialisation in SpecConstr
-----------------------------+----------------------------------------------
Reporter: simonpj | Owner:
Type: feature request | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 6.8.3
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: Unknown
Os: Unknown |
-----------------------------+----------------------------------------------
Changes (by simonpj):
* cc: [EMAIL PROTECTED] (added)
Comment:
Roman says: Yes, as long as the definition of recursive doesn't include
things like
{{{
data T a where
Pair :: T a -> T b -> T (a,b)
...
}}}
and similar constructs for indexed types. I'm not really convinced
about this idea, though. What is so special about recursive
constructors? And why is generating all specialisations in this
particular case bad at all? In the end, all but the one for
`dropComment (x:xs`) are eliminated which roughly doubles the code size.
There are a couple more tiny leftovers but that's only because GHC
isn't even trying to get rid of them. To be honest, I don't quite see
the problem here.
In fact, in this example `SpecConstr` actually performs a fairly complex
optimisation which, unfortunately, doesn't bring much (I think;
benchmarking the lexer with and without `SpecConstr` would be useful).
{{{
> dropComment (' ':'-':'-':' ':_) = []
> dropComment (x:xs) = x : dropComment xs
> dropComment [] = []
}}}
Without `SpecConstr`, we have:
{{{
dropComment (' ':'-':'a':...)
-> dropComment ('-':'a':...)
-> dropComment ('a':...)
}}}
`SpecConstr` skips the second step (i.e., saves a recursive call)
because it knows that the argument won't match the first equation. For
Haddock, this isn't a big win unless the input file contains a lot of
space/dash sequences. However, I can easily imagine programs where
this optimisation would be very desirable.
Roman
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2598#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
