SSA

[Matthew Fluet]

> > I'm currently trying to track down a bug in prodcons.sml.  Very strange;
> > only shows up when running the regressions script and seems to be related
> > to the new removeUnused pass for ssa.
> 
> Make sure it's not the same limit check bug :-).  Try running with big
> heaps.

Well, some GC bug is contributing to prodcons.sml:

[fluet@lennon prodcons]$ mlton-stable -g prodcons.sml 
[fluet@lennon prodcons]$ ./prodcons @MLton gc-summary gc-messages fixed-heap 30k --
Starting gc.
fromSpace 16,384  toSpace 16,384
Finished gc.
time(ms): 0
live(bytes): 9,752 (59.5%)
gc.c 581: assert(0 == s->fromSize or (s->frontier <= s->limit + LIMIT_SLOP
and s->limit == s->base + s->fromSize - LIMIT_SLOP)) failed.
Aborted

That's using the 20011006 release.  It's very strange; fixed-heap of 20k
works fine.  30k asserts about 4 out of 5 times.  Gotta love
non-determinism.


If I disable that assert under my current sources, I get:

[fluet@lennon prodcons]$ mlton -g prodcons.sml 
[fluet@lennon prodcons]$ ./prodcons @MLton gc-summary gc-messages fixed-heap 30k --
/tmp/fileaLwRgn.0.s 0: GC
Starting gc.
fromSpace 16,384  toSpace 16,384
Finished gc.
time(ms): 0
live(bytes): 9,892 (60.4%)
/tmp/fileaLwRgn.0.s 0: GC
Starting gc.
fromSpace 16,384  toSpace 16,384
Finished gc.
time(ms): 0
live(bytes): 10,736 (65.5%)
gc.c 447: assert(top == bottom - WORD_SIZE) failed.
Aborted

This worries me a little more; it means that sum of the frame-sizes
doesn't equal the total stack size.   Not to mention the fact that my G2
self compiles fail with Out of memory in closure conversion on machines
with .5GB.



BTW, it's probably a good idea to run regressions with -g every once in a
while.  I discovered an unrelated bug in the backend; maxFrameSize is
computed from the maxStackOffset, but every actual frame rounds up by
wordAlign-ing.  So, you can end up with an actual frame size greater than
the computed frame size.  Wrapping maxStackOffset with wordAlign fixes it.