[MLton-devel] Problem with -exn-history true

Matthew Fluet Matthew Fluet <fluet@CS.Cornell.EDU>
Tue, 20 Aug 2002 15:38:19 -0400 (EDT)


> Looking at constant-prop, it never drops blocks, so it must be shrink that
> has a bug.

I don't think that there is anything specifically wrong with shrink, other
than the fact that I'm not too clear on precisely what is guaranteed after
a shrink.  I suspect that what is happening in this case is a peculiarity
of the useless pass.  Most passes either do an analysis by walking the
control-flow-graph (either by explicitly constructing it or the dominator
tree or implicitly by Transfer.foreachLabel calls) or iterate over the
vector of blocks.  Useless does both (the call to analyze doing the cfg
walk, while the rewrite iterates over the blocks), so it's getting burnt
by the analysis not seeing a block that the rewrite touches.

The "problem" with shrink is that it (mostly) does a DFS walk of the CFG.
In this case, it follows a path from the start block to the return block
(L_85404) that doesn't hit the simplifiable case.  When it hits the return
block, it sees the HandlerPop.  It can't delay the rewrite of this block,
so it needs to make a snap decision about keeping or dropping the
HandlerPop.  Since the non-tail calls that use the handler were all
reachable in the initial walk, we keep the block, and force the keeping of
the handler.  Later, as we finish the DFS, we hit the simplifiable case,
which deletes everything reachable from that point, except for the handler
which has been forced already.

The shrinker seems the right place for a fix, but it's not clear that
there is an easy fix. Possible solutions:
1. yet one more iteration over the blocks to drop unreachable blocks;
   but, we'd also need to rewrite any block with a HandlerPush/Pop of
   a dropped block.
2. rewrite via a queue, where blocks with HandlerPop are enqued at the
   rear of the queue while other blocks are enqueued at the front; then we
   ought to rewrite all reachable non-tail calls that are have a
   handle before rewriting the block that pops the handle.  But that seems
   a little complicated.




-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel