OCaml ppc64 support

[Gustavo Luiz Duarte]

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.
>