#5256: code in an "else" branch that is never executed still does influence
runtime (Vectorizer?)
-------------------------------+--------------------------------------------
Reporter: j.waldmann | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.0.3 | Keywords:
Testcase: | Blockedby:
Os: Linux | Blocking:
Architecture: x86_64 (amd64) | Failure: None/Unknown
-------------------------------+--------------------------------------------
Comment(by daniel.is.fischer):
The problem is that with the undefined, GHC sees that the else-branch is
uninteresting and ignores the complicated recursion, thus effectively we
get
{{{
foldb_cap cap ... = if cap <= 1 then V.foldl' ... else undefined
}}}
which is simple enough to be inlined, the function parameters get inlined
too, so we get a nice explicit loop
{{{
$s$wfoldlM'_loop_s3Am [Occ=LoopBreaker]
:: GHC.Prim.Int#
-> GHC.Prim.Int#
-> GHC.Prim.Int#
-> (# GHC.Types.Int, GHC.Types.Int #)
}}}
with primops.
In the other case, GHC passes the function arguments to the recursive
calls and it doesn't see that it could inline them here (it's only ever
called once from main, so it never gets passed other functions), leading
to a loop
{{{
$s$wfoldlM'_loop_s3EE [Occ=LoopBreaker]
:: GHC.Prim.Int#
-> (GHC.Types.Int, GHC.Types.Int)
-> (# GHC.Types.Int, GHC.Types.Int #)
}}}
calling the function arguments in each iteration.
A manual static argument transformation for the two function arguments
{{{
foldb_cap cp strt f g xs = work cp strt xs
where
work cap e s = if cap <= 1 then ... else ... work ...
}}}
makes it clear that it never gets different function arguments, allowing
them to be inlined (since it's not exported and only called once, they
aren't inlined if foldb_cap is exported unless you have an INLINE pragma
on foldb_cap) here, again giving the primop loop.
So perhaps GHC should be keener to SAT function arguments?
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5256#comment:2>
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
