OCamlopt is able to spill floating point register.
You can even see with -dalloc that the code will spill a floating point register in the loop.

The problem observed is not because of spilling but simply because of float boxing and compilation of recursive calls.
The loop seems to compile down to an efficient code ended by a jump, but float unboxing is done in a much earlier pass in the compiler (cmm).

Passing -dcmm to the compiler, we can see that before the recursive call to loop the float is boxed again.
At this point, it is just a regular ocaml function call, taking boxed float.

A simpler code to observe this behavior:

let rec test f =
  test (f +. 1.0)

let () = test 0.0

will box at every iteration.

Le 19 déc. 2016 à 17:41, Gerd Stolpmann <info@gerd-stolpmann.de> a écrit :

Michael,

look here, it's the "definitive source":
https://github.com/ocaml/ocaml/blob/trunk/asmcomp/amd64/proc.ml

Windows is in deed different. I don't have enough insight into the
register spilling algorithm to say whether this has a significant
effect, though. OCaml code never keeps registers alive, and thus I
would bet the spilling algorithm is designed for that, and it is
probably not tried to move values preferably to xmm6-15 in order to
avoid spilling during C calls. But that's just a hypothesis... Does
somebody know?

Gerd


Am Montag, den 19.12.2016, 14:52 +0000 schrieb Soegtrop, Michael:
Dear Gerd,


When you call a C function like cos it is likely that this
happens because the C calling conventions do not preserve the FP
registers
(xmm*). This could be improved if the OCaml compiler tried
alternate places for
temporarily storing FP values:
For Windows this doesn't seem to be true. See e.g.:

https://msdn.microsoft.com/en-us/library/ms235286.aspx

which states that XMM0..XMM5 are volatile, while XMM6..XMM15 must be
preserved.

I think for Linix you are right. I couldn't find a better reference
than Wikipedia:

https://en.wikipedia.org/wiki/X86_calling_conventions

see "System V AMD64 ABI" there.
 
This reference contains a good overview, which matches the above data
in table 4:

http://www.agner.org/optimize/calling_conventions.pdf

So on Windows, there is for sure no need to save XMM6..XMM15, while
on Linux this seems to be an issue.

Best regards,

Michael
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
My OCaml site:          http://www.camlcity.org
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------