OCaml plans on POWER7/POWER8 (ppc64, ppc64le) in Rawhide

[Dan Horák]

On Tue, 8 Sep 2015 20:02:08 +0100
"Richard W.M. Jones" <rjones at redhat.com> wrote:

> OCaml is a statically-safe programming language derived from ML which
> compiles to very fast native code.  It contains native code backends
> for most architectures (all Fedora primary & secondary arches except
> s/390x in fact).

the s390x situation is expected to change in the future :-)

> Currently Fedora downstream carries two non-upstream backends:
> For ppc64 (big endian), a backend was written many years ago by David
> Woodhouse and was upstream for a time, but was dropped when the
> PlayStation 3 stopped supporting Linux.  For ppc64le (little endian /
> POWER8) IBM's Michel Normand contributed a native code backend last
> year.  The upstream project always carried a ppc (32 bit) backend, but
> we didn't use it and it's not very interesting for us.
> 
>   https://git.fedorahosted.org/cgit/fedora-ocaml.git/log/?h=fedora-24-4.02
> 
> Red Hat and IBM have provided help and loaned equipment to the
> upstream project, and as a result upstream have now added ppc64 and
> ppc64le backends.  This work was merged at the end of August.  These
> backends were inspired by the Red Hat & IBM work but are not
> derivatives.  For details see:
> 
>   https://github.com/ocaml/ocaml/pull/225
> 
> So what I want to do is add the new backends [actually it's a single,
> combined and extended ppc/ppc64/ppc64le backend] to Fedora Rawhide,
> and drop our non-upstream backends.
> 
> I have so far cherry-picked the merge commit on top of our Fedora
> OCaml tree, and I have dropped the downstream ppc64/ppc64le commits
> from our tree.  (This is not pushed yet so doesn't appear in the
> git.fedorahosted.org link above.)
> 
> I have tested it on ppc64le to check that the compiler compiles
> itself.  A scratch build of the compiler with the new backend is here
> (I reserve the right to make further changes, this is just a
> preliminary test build):
> 
>   http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2741551
> 
> I used this to compile some ocaml-* packages on ppc64le, with -- it
> has to be said -- mixed results.  There are two compiler bugs
> revealed.  This compiler won't be able to compile all the ocaml-*
> packages on POWER.  However because of the depth of dependencies, I
> cannot easily do scratch builds to find out which packages will be
> broken.
> 
> Hence I'd like to do a full rebuild, again, to see what breaks.  This
> *shouldn't affect primary architectures at all*, but will probably
> leave some broken ocaml-* packages on the ppc64/ppc64le secondary
> arches.
> 
> We've actually done two complete rebuilds during the F24 development
> cycle already, which in a way is good because it means I know how long
> it should take, and I'm confident that the scripts I use will work
> again:
> 
>   http://git.annexia.org/?p=goals.git;a=blob;f=fedora_ocaml_rebuild.ml;h=13a8c016b34a3d92cbb118d44b87c9b32d6d09af;hb=HEAD
> 
> So I'm pretty confident the primary arch rebuild will go fine, since
> it's not affected by any of the above changes - it's basically just a
> release bump.  We don't even need to use a side tag for this because
> the "old" and "new" packages can be mixed on x86 - they are the same.
> 
> The plan for ppc64/ppc64le would then be to fix the bugs revealed in
> the rebuild with upstream help.
> 
> Any comments?

Moving to upstream code generator is definitely a good thing, having
some broken ocaml-* packages for a limited period of time, until the
compiler is fixed, is acceptable. My only concern is about the various
virt related tools that are written in OCaml and are needed during the
release engineering tasks.


		Dan