#4941: SpecConstr generates functions that do not use their arguments
---------------------------------+------------------------------------------
Reporter: simonpj | Owner:
Type: task | Status: new
Priority: normal | Milestone: _|_
Component: Compiler | Version: 7.0.1
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: Runtime performance bug
---------------------------------+------------------------------------------
Comment(by batterseapower):
I've stared at para for a while and can't see anything obviously bad going
on to cause the allocation increase.
I did notice one suspicious thing, but I don't think it's actually a
problem. Before we have something like:
{{{
let wild = (a, b)
$j = \x y -> case BIG of A -> wild; B -> (x, y)
in if e1 then $j c d else $j e f
}}}
CPRish $j gets worker/wrappered with this new invocation of the demand
analyser so we get:
{{{
let $j = \x y -> case BIG of A -> (# a, b #); B -> (# x, y #)
in if e1 then case $j c d of (# k, l #) -> (k, l) else case $j e f of (#
k, l #) -> (k, l)
}}}
This causes reboxing if "wild" is mentioned anywhere else, since sharing
of the allocation is lost. The wild binding does actually get eliminated
by the simplifier. However, I've managed to convince myself that wild was
probably actually used Once in the input so this is in fact OK.
So in summary I don't think the nofib results are going to get any better
than that. Take it or leave it :-)
Personally I've seen this change making a difference to numerical loops
that pass around STUArray. After SpecConstr (which unpacks the STUArray
data type) several of the STUArray fields will typically be dead, though
we may still want e.g. the MutableByteArray# inside. Eliminating these
useless arguments from numerical loops using STUArrays might be a cool
enough reason to warrant this change.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4941#comment:16>
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
