On 17/09/2009 09:38, Ben Lippmeier wrote:
Hi All,
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?
I don't know why specifically there's an unreachable loop in the Cmm
code, but I think the NCG should cope with it - otherwise we have a new
invariant on the form of Cmm that we'd have to maintain elsewhere and
that's fragile.
However, that Cmm does look suspicious and we should investigate that too.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
