[MLton-devel] allocation performance improvements

[Matthew Fluet]

> Of course, this are only valid if list order doesn't matter.  It seems
> like it often doesn't to me, but I'd rather get the advice of an
> expert :-).  Matthew, could you take a look through
> x86-allocate-registers.fun and do those replacements when possible?
> I'm hoping for a 10% or so decrease in total self-compile allocation.

Sure; I'll try to take a look at that this evening.  IIRC, the order of
elements in the register map doesn't ever matter, so those maps and
filters can be reversed without penalty.  In the very early days of the
native codegen, I had toyed with some alternative representations of the
register map (e.g., ensuring that we could never have two entries for the
same register) using arrays or vectors, but I never saw a speedup.  Of
course, I think that was really early on, where we hadn't gotten to a self
compile, so I was measuring different SML/NJ G0's MLtons.  I'll give some
thought to that later on.





-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel