#3552: Unreachable code in optimised CMM code
-------------------------------+--------------------------------------------
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 6.14 branch
Component: Compiler | Version: 6.10.4
Severity: normal | Keywords:
Difficulty: Unknown | Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
-------------------------------+--------------------------------------------
Ben found that GHC is gnerating some unreachable C-- code. While the NCG
should handle that case, it's curious, so I'm recording it as a ticket to
look at with the new codegen pipeline.
While working on the NCG I've come across this:
{{{
b...@mavericks:~/devel/ghc/ghc-head-incoming> inplace/bin/ghc-stage1 -c
rts/Updates.cmm -ddump-opt-cmm
==================== Optimised Cmm ====================
...
cp: _ch::I32 = I32[_cb::I32 + 4];
I32[_ch::I32] = _c6::I32;
I32[_cb::I32 + 4] = _ch::I32 + 4;
I32[_c6::I32 + 0] = stg_IND_OLDGEN_info;
jump (I32[Sp + 0]) ();
cq: goto cq;
}
}}}
The goto instruction at cq: is unreachable.
However, in nativeGen/RegAlloc/Linear/Main.hs we have:
{{{
{- from John Dias's patch 2008/10/16:
The linear-scan allocator sometimes allocates a block
before allocating one of its predecessors, which could lead to
inconsistent allocations. Make it so a block is only allocated
if a predecessor has set the "incoming" assignments for the block, or
if it's the procedure's entry block.
BL 2009/02: Careful. If the assignment for a block doesn't get set for
some reason then this function will loop. We should probably do some
more sanity checking to guard against this eventuality.
-}
}}}
I'm in a situation where the linear allocator is looping because it's
trying to wait for a predecessor of cq: to set the incoming register
assignments, but that never happens because it's unreachable.
I don't know why it wasn't looping until now, maybe because i've wibbled
some function and caused some previously undemanded computation to hit
this loop.
Do we want the allocator to accept the above code, or just panic? Is
this a bug in the Cmm code generator, or is there a good reason why
there is an unreachable loop in this code?
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3552>
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
