MLton (fwd)

[Matthew Fluet]

> > > There seems to be a minor increase in code size, but I'm not
> > > precisely sure why.
> > 
> > Could it be due to the fact that you used notInLoop instead of inLoop
> > when deciding what to carry in registers?  
> 
> Could be, although pseudo-regs shouldn't be live around loops, so I'm
> surprised that anything changed with -native-live-false.

The assembly for the 20011213 stable compiler and today's compiler are
identical, so I don't really know where the extra size is coming from.

Actually, I think I just figured it out.  Due to the way I have scripts
and stuff set up, stabilizing ends up building the runtime from scratch,
but just building a new version of the compiler does not.  So,
mlton-stable was using a libmlton.a built on 20011213, but the "current"
compiler has a libmlton.a built on 20011211.  I don't recall exactly what
changed between those two dates, but the files have different sizes.

So, I rebuilt libmlton.a for the "current" compiler, but that doesn't fix
the size problem.  The two libmlton.a are still slightly different in size
(the "current" is larger).  I guess there isn't anything that guarantees
that the 20011213 version was really using up-to-date sources, but I would
have thought so; I recall needing to stabilize to a new version to deal
with the changes to threads and conts.

Anyways, I don't think it's a problem with the codegen; I think it's
the runtime.  Further evidence of this fact is that the extra size is
about 500 - 650 bytes in all the programs; if it was in the codegen (or
anywhere else in the compiler), I would expect hamlet and mlyacc to be
correspondingly larger.

As I said before, the assembly is identical, so I think that the extra
time on vector-concat was just noise.