SSA backend

Matthew Fluet fluet@CS.Cornell.EDU
Mon, 15 Oct 2001 15:35:10 -0400 (EDT)


> > However, I'm getting strange errors with this and mllex (and mlyacc).  The
> > resulting ssa program type-checks, but register allocation in the backend
> > fails. 
> ...
> > I don't claim that remove-unused.new.fun is 100% bug-free, but I also think
> > that an ssa program that type checks (i.e., satisfies the SSA condition),
> > shouldn't be generating bogus liveness info in the backend.
> 
> Yeah, except for Function.checkHandlers, which isn't on in the type checker yet
> because I haven't debugged it.  Also, the bug may not be due to
> remove-unused.new.fun, it may be due to the fact that there are two passes of
> remove at the end of the optimize cycle instead of one.  Anyways, I am
> investigating.

How would a second pass of remove at the end of the optimize cycle cause
problems?

Let me know if you have any good techniques for debugging SSA functions on
the size of mllex's main_0.  dot dies pretty quickly on the .dot file, and
I get lost in the SSA file pretty quickly.

> > One other thing I added -- to allocate-registers.fun, I made any
> > appearance of a Set* statement imply hasHandler.
> 
> Makes sense.  It would be nice if removeUnused got rid of the unused Set*
> statements.  Although it really doesn't matter since the new approach will be to
> infer/insert them after all optimization is done, and that almost certainly
> won't introduce bogus ones.

Well, the sooner we can assume that SSA optimizations will never see Set*
statements, the better.  I'd suggest getting at least a trivial one going
soon.