[GHC] #13429: Optimizer produces Core with an infinite <<loop>>
GHC
ghc-devs at haskell.org
Mon May 1 16:55:15 UTC 2017
#13429: Optimizer produces Core with an infinite <<loop>>
-------------------------------------+-------------------------------------
Reporter: lehins | Owner: (none)
Type: bug | Status: new
Priority: high | Milestone: 7.10.4
Component: Compiler | Version: 8.0.2
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: Runtime crash | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by dfeuer):
I reduced the test case again. See `LoopReduced2.hs` and `mainReduced2.hs`
(you'll have to rename the `LoopReduced2.hs` file to `Loop.hs` to
compile). I attached `-dverbose-core2core` results before and after the
early inlining patch as `dumpbefore.tgz` and `dumpafter.tgz`. I haven't
figured out where things go wrong just yet, but if you look at
`dumpbefore/main.dump-simpl`, you'll see
{{{#!hs
Rec {
-- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0}
Main.$s$fArrayXe_$dNum [Occ=LoopBreaker] :: Num Word8
[GblId, Str=b]
Main.$s$fArrayXe_$dNum = Main.$s$fArrayXe_$dNum
end Rec }
}}}
which is very obviously very bad. For some reason we're "optimizing" a
dictionary into a reference to itself! My vague guess is that GHC sees
that it can get a `Num Word8` dictionary from an `Array` or `ColorSpace`
dictionary, and that it can get `ColorSpace` and `Array` dictionaries from
`Num` ones, and makes some very bad decisions. I have no idea why the
early inline patch fixes this, but I'm rather nervous about it being a
proper fix.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13429#comment:13>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list