discussion of X86 floating point on comp.lang.ml

[Matthew Fluet]

> Matthew, I don't know if you follow comp.lang.ml, so just in case, you will
> probably find the following article interesting.
> 

Thanks for the pointer; I generally follow comp.lang.ml but I haven't
combed through all the ICFP entry posts, as most of them got cc-ed to
MLton anyways.

I looked at raytrace quick and got the following:

[fluet@lennon tests]$ grep "[[:blank:]]f" raytrace_s0001.s | wc -l
   4589
[fluet@lennon tests]$ grep "fxch" raytrace_s0001.s | wc -l
    455
[fluet@lennon tests]$ grep "%st([1-9])" raytrace_s0001.s | wc -l
   1049
[fluet@lennon tests]$ grep "%st([7])" raytrace_s0001.s | wc -l
      5
[fluet@lennon tests]$ grep "%st([7])" raytrace_s0001.s        
        fxch %st(7)
        fmulp %st, %st(7)
        fxch %st(7)
        fxch %st(7)
        fxch %st(7)


So, out of 4500 floating point instructions, 10% were exchanges.
Approximately 1000 instructions referenced non-top floating point stack
values.  Only 5 instructions touch the bottom most stack value; and most
of those were exchanges.  However, looking at the assembly, almost all of
those exchanges were followed by a fstpl to a localdouble
pseudo-register.  So, it was the result of register pressure -- and the
nature of the stack is to put the oldest values at the bottom, which are
the ones I spill first.  Unfortunately, the xchg has the byproduct of now
putting the newest value at the bottom of the stack, which, my impression
from the post above, are costly to access.  Certainly something to think
about.