Register d7 trampled by float_of_int #5731
Original bug ID: 5731
Code generation error. A value is loaded into d7. A call to float_of_int generates code that loads s14, which overwrites the value in d7 (low order mantissa). The value in d7 is then used in a later computation, but the value has been destroyed.
If I make small changes to the code, the load of d7 happens after the float_of_int computation, and things work OK. Possibly some constraints on instruction orderings aren't being applied properly.
Steps to reproduce
Need a version of ocamlopt with support for armv7 with hardware floating point (VFPv3).
Then compile the following code:
let rate_pos scounts : float =
My compile line looks like this:
I'm attaching the full assembly code output. The section with the error contains the code for the following lines:
in let f = float_of_int numer /. float_of_int denom
The erroneous code looks like this (with added annotations):
I ran my tests on a stock OCaml 4.00.0 compiler in an emulated Linux ARMEL environment under QEMU on OS X. I don't think this affects the results; I see exactly the same instruction sequence in my experimental cross-compiler builds (compiling for iOS under OS X).
Here is my configure line:
(Need to use gnueabihf to get VFPv3 support.)
Then build ocamlopt as usual.
The text was updated successfully, but these errors were encountered:
Comment author: meurer
Jep, the issue is in the scheduling code, that doesn't care about the destroyed_at_oper constraint. There are several possible fixes for this. Either we adjust schedgen to respect destroyed_at_oper, or don't use scheduling at all on arm (just like amd64/i386), or we adjust the arm code generation to avoid the hidden s14 usage for inttofloat, floattoint and single Load/Store.
Xavier, any opinions on this?
Comment author: jeffsco
I installed the new schedgen.ml into my modified version of 4.00.0+beta2 and rebuilt the app that was failing before. By eye, the spot that was broken before is fixed (d7 is loaded after the float_of_int calculation). I ran the app, and it works perfectly on the device. I also built and ran our other app (another card game), and it also ran perfectly. The whittled-down example above also looks perfect by eye (as I would expect). So, things are looking excellent to me.
One limitation of this test is that I installed Xavier's scheduling change into my worktree. If you like I can instead apply my iOS patches to the INRIA trunk and try that instead. The results will almost certainly be the same, but it feels slightly more rigorous (though a little more trouble for me to set up). Let me know if you'd like me to run this test (or any other test).
(Also let me know if I'm supposed to click a button somewhere in Mantis to say I've given feedback! I'm hoping these notes are sufficient.)
Comment author: meurer
Ok, so this is fixed in trunk then. Xavier, do you want to merge that into the 4.00 branch?
Concerning the iOS merge, I already started work on this here:
You may want to clone that and contribute the missing bits and pieces. I'll merge everything into upstream once working and time permits.