SSA backend
Matthew Fluet
fluet@CS.Cornell.EDU
Sat, 13 Oct 2001 13:32:21 -0400 (EDT)
I checked in a fix for the x86-codegen bug.
I think this works o.k. with my previous remove-unused.fun.
I also checked in a remove-unused.new.fun, which does the following:
removes unused datatypes
removes unused datatype constructors
removes unused datatype constructor arguments
removes unused functions
removes unused function arguments
removes unused function returns
removes unused blocks
removes unused block arguments
removes unused statements (variable bindings, unused SetHandler's)
removes unused handlers from non-tail calls (mayRaise analysis)
removes unused continuations from non-tail calls (mayReturn analysis)
removes calls to non-side-effecting, non-raising, terminating functions
This basically incorporates unusedArgs and some of raiseToJump. The
resulting code is a little messy; the shrinker should take care of
eliminating wrappers.
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. If you compile with -keep ssa -keep-diag backend and look at
mllex.backend.diagnostics, you'll see that the liveness analysis computes
that two variables are live at the beginning of main_0 -- which clearly
doesn't make sense. 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.
One other thing I added -- to allocate-registers.fun, I made any
appearance of a Set* statement imply hasHandler. When you eliminate the
handler for a non-tail call (i.e., the raise-to-jump analysis), you have
to delete the SetHandler statement, because if the only use of that block
was in the non-tail call's handler, then the resulting program graph won't
be connected if you leave the block. But, this might leave some
SetExnStack statements around that don't do anything useful. But, the
backend will try accessing the code and link slots, so we need to allocate
them.