#2754: Strictness analyzer fails on an implementation of foldl
--------------------------------------+-------------------------------------
Reporter: nimnul | Owner:
Type: run-time performance bug | Status: closed
Priority: normal | Milestone:
Component: Compiler | Version: 6.8.3
Severity: normal | Resolution: invalid
Keywords: | Difficulty: Unknown
Testcase: | Architecture: x86
Os: Windows |
--------------------------------------+-------------------------------------
Comment (by nimnul):
Replying to [comment:4 dons]:
> nimul, this might explain the behaviour you see:
>
> {{{
> -- We write foldl as a non-recursive thing, so that it
> -- can be inlined, (skipped)
}}}
foldC is recursive, but is optimized correctly. So recursion in foldA is
not an argument.
> If I remember correctly from the discussion with nimul in #haskell, his
view was that the strictness analyser wasn't sufficiently powerful: it
doesn't do magic.
No optimizer does magic. But optimizers do evolve, and new versions of say
gcc perform more and more optimizations. GCC team at least accepts cases
when GCC optimizer fails to produce optimal code as enhancement requests.
You can find a lot of such requests in the GCC bug tracker, for example,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28364.
Is there any reason why GHC team don't follow them and don't accept such
requests?
Is there any reason why my case is not a failing simple test case for GHC
optimizer, and thus cannot be accepted as an enhancement request? The
current behaviour (not inlining op) and the desired behaviour (to inline
op if it's known to be strict and then proceed with already implemented
optimizations) are clear.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2754#comment:6>
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
