Returning a known constructor: GHC generates terrible code for cmonad
Lennart reports that GHC generates very poor code for his cmonad package.
If you want to look at a simple example, look at the Inf.hs example
included in package cmonad-0.1.1.
It's very simple, and ghc generates fantastically bad code for it.
It would be great if you could nail down why it's so amazingly unoptimal. Even with everything inlined and no overloading left, ghc seems to ignore the INLINE directives and use dictionaries left and right. When I looked at it a year ago or so, it was a return of one constructor in a sum. That is, a function always returns the same constructor, so the case analysis of the return value is not needed; it should be returned as an unboxed tuple instead
Another unrelated problem, I think, is that ghc needs to promote in-memory variables to registers when possible. Perhaps the new code generator has such a transformation?
Trac metadata
| Trac field | Value |
|---|---|
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture |