RSSA backend

Matthew Fluet fluet@CS.Cornell.EDU
Fri, 18 Jan 2002 14:26:21 -0500 (EST)


> Unfortunately, it looks like barnes-hut and nucleic will continue to
> prevent us from being faster than every other SML compiler on every
> benchmark.

Yeah.  I combed through the old emails to look at the results you got
compared to the broken limit check inserter, and neither of those were
significantly affected, so I don't think we'll get much of anything back
with coalescing of limit checks.

I'm updating the documentation to reflect the MLton.Profile structure.
I'll probably make a more involved profiling.sml example to show off the
new facilities.  One note, that I mentioned before, is that we're getting
-d 1 labels corresponding to RSSA rather than corresponding to SSA.
I think this is bad, both because -p saves .ssa and not .backend.machine;
furthermore, even saving .backend.machine with -keep-pass backend isn't
quite right, because backend.fun introduces yet more Machine.Block.t's, so
the labels in the profiler are sort of in limbo.

Thoughts? One solution might be to push back the profileInfo in
Machine.Block.t's to Rssa.Block.t's.  The ssa-to-rssa translation would
fill in the profileInfo appropriately.  The complication is that all new
Rssa.Block.t's (i.e., all the limit checks, array inits, etc.) would need
to fill in the profileInfo.  It really comes down to how often new blocks
are created that don't have immediate access to the right profileInfo of
their "parent" block.