[MLton-devel] cvs commit: C codegen cleanup

[Stephen Weeks]

> As regards stackTop, nextFun and assorted very busy variables, I
> tried a long time ago to allocate them a global register. GCC
> permits this by saying for instance:
> 
> 	register int nextFun asm("g5");
> 
> (see http://gcc.gnu.org/onlinedocs/gcc/Global-Reg-Vars.html). The
> speedup was quite significant under SPARC though I cannot remember
> the exact figures. I wonder if this still would pay off with the
> current code.

I added an #if to c-chunk.h that causes frontier and stackTop to use a
register spec when compiling on SPARC.  On most benchmarks, this had
no effect.  On a few benchmarks, it shrank the code marginally, but
had no run time effect.  On a few benchmarks, it caused a bug.  Below
are the benchmarks that showed some effect.

These results are a bit surprising, so maybe I did something wrong.
If someone can show any positive effect from using register specs on
SPARC, I'd be interested to see it.

MLton0 -- /usr/local/bin/mlton 
MLton1 -- /usr/local/bin/mlton -cc-opt -DREGISTER_FRONTIER_STACKTOP

run time ratio
benchmark         MLton0 MLton1
hamlet              1.00      *
knuth-bendix        1.00   1.00
mlyacc              1.00   1.00
model-elimination   1.00      *
tsp                 1.00   0.99
vliw                1.00      *

size
benchmark            MLton0    MLton1
hamlet            1,401,786 1,401,018
knuth-bendix        125,068   125,004
mlyacc              540,181   539,957
model-elimination   755,844   755,492
tsp                  94,634    94,378
vliw                427,956   427,956

compile time
benchmark         MLton0 MLton1
hamlet            453.43 449.12
knuth-bendix       18.25  18.11
mlyacc            185.90 184.88
model-elimination 181.61 179.24
tsp                 9.69   9.53
vliw               98.57  97.53

run time
benchmark         MLton0 MLton1
hamlet             80.83      *
knuth-bendix       59.52  59.56
mlyacc             54.43  54.69
model-elimination 327.36      *
tsp                39.65  39.38
vliw               62.12      *


-------------------------------------------------------
This SF.net email is sponsored by: If flattening out C++ or Java
code to make your application fit in a relational database is painful, 
don't do it! Check out ObjectStore. Now part of Progress Software.
http://www.objectstore.net/sourceforge
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel