#3181: Regression in unboxing
-----------------------------------------+----------------------------------
Reporter: dolio | Owner:
Type: run-time performance bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 6.10.2
Severity: normal | Resolution:
Keywords: unboxing boxing | Difficulty: Unknown
Testcase: | Os: Linux
Architecture: x86_64 (amd64) |
-----------------------------------------+----------------------------------
Changes (by simonpj):
* difficulty: => Unknown
Comment:
Thanks for a nice well-characterised bug report.
I can't reproduce it because you didn't include `Data.Vector`. Could you
do so? (It's v helpful for tickets to be self contained where possible.)
If it's big, you may be able to cut it down to just what the test case
needs. I don't necessarily even need to run it: just to compile it. So
you may be able to go
{{{
module Vector( foo ) where
foo :: Int -> Int
foo = error "stub"
}}}
or stuff like that.
Anyway, I have seen cases like this before. Here's the relevant comment
from `Simplify.lhs`:
{{{
Note [Case binders and join points]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Consider this
case (case .. ) of c {
I# c# -> ....c....
If we make a join point with c but not c# we get
$j = \c -> ....c....
But if later inlining scrutines the c, thus
$j = \c -> ... case c of { I# y -> ... } ...
we won't see that 'c' has already been scrutinised.
An alternative plan is this:
$j = \c# -> let c = I# c# in ...c....
but that is bad if 'c' is *not* later scrutinised.
}}}
Whether or not it happens depends delicately on exactly when inlining
takes place. Hence (I think) the regression.
I have a fix for my test HEAD, but I'd like to use your example as a test
case.
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3181#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
