Hi Richard,
Thanks for the work you have done. I would be happy to help on whatever I can. I think that if you describe the steps to reproduce the issue on bugz #826649 it would be a good start point for me to jump in.
Also, do you hang out on freenode? I'm always on channel #fedora-ppc.
[]'s Gustavo
On 05/30/2012 02:19 PM, Richard W.M. Jones wrote:
I just spent a couple of days studying and attempting to fix ppc64 support in the ocaml package.
Background information
OCaml is a nice, fast functional language. We carry ~ 70 OCaml- related packages in Fedora. Since OCaml compiles to native code, it needs a specific backend to be written for each target. Without this it falls back to using a bytecode interpreter which is ~10 times slower, so the backend is not required, but highly desirable.
Native code backends are not large nor especially hard to write. The ppc64 backend in Fedora has just under 2000 lines of code. Moreover a lot of that code is identical to the ppc (32 bit) backend.
486 asmrun/power64-elf.S 83 asmcomp/power64/arch.ml 989 asmcomp/power64/emit.mlp 241 asmcomp/power64/proc.ml 18 asmcomp/power64/reload.ml 65 asmcomp/power64/scheduling.ml 103 asmcomp/power64/selection.ml 1985 total
Upstream, there are backends for many different architectures. Of interest to this list, there is a backend for ppc (32 bit), and ppc64. *However* the upstream ppc64 backend ONLY works on Mac OS X, because it makes assumptions[1] about the architecture and the assembler which don't work with GNU as.
A long time ago, David Woodhouse wrote or modified a ppc64 backend, which we are now carrying as a separate, non-upstream patch in Fedora. It generally works, although it has several bugs, of which more later.
Upstream rejected this backend because they don't have the hardware required to maintain it.
What I did
Because the ppc64 backend is so hard to maintain as a patch, I broke it out into a git repository. This also makes maintaining other patches easier (in particular my backport of the new ARM code generator). If you need access to this, please request it in the usual way via fedorahosted:
http://git.fedorahosted.org/git/?p=fedora-ocaml.git
After doing this, I rewrote parts of our ppc64 backend so that they more closely match the upstream ppc backend, ie. so that the differences in the following commands are minimized as far as possible:
diff -urb asmcomp/power64 asmcomp/power | less diff -urb asmrun/power64-elf.S asmrun/power-elf.S | less
Note that I did NOT make any functional changes to the ppc64 backend when doing this.
I also compiled a number of packages using our ppc64 backend. I noticed that ocaml-camomile wouldn't compile. One module of this program contains a very large "entry" function. The "entry" function of a module is the name given to all the toplevel code in a module which runs when the module loads and isn't a part of any function definition in the module. By experimentation I found that when the entry function exceeds around 26 kbytes, it causes corruption of the minor heap. This is some sort of bug in the code generator, but I wasn't able to determine what, and would appreciate any help in finding it:
https://bugzilla.redhat.com/show_bug.cgi?id=826649
I also found a variety of other bugs which all seem to be caused by the smaller available default stack on ppc64 combined with the larger number of registers (therefore more stack spillage). I will report these upstream as I come across them, but the most serious is this one:
http://caml.inria.fr/mantis/view.php?id=5368
How I need help
I could do with help on #826649, particularly from ppc64 codegen experts. Also on compiling any remaining ocaml-* packages on ppc64 (most already done) and checking that they actually function. Also on identifying any remaining ocaml packages that have ExcludeArch: ppc64, removing that and if necessary fixing any bugs found.
Rich.
[1] I'm not precisely sure what assumptions it's making, and I could be wrong on this point, but I certainly couldn't get the upstream ppc64 backend to work on Fedora16/ppc64, and I also noticed the assembler syntax is somewhat different from gas and incompatible.