Geode tuning

[Bernardo Innocenti]

This is a summary of the current status of AMD Geode
optimizations that we might be interested in.

Sorry for the long Cc list, I just wanted to make sure
all interested parties can read and comment even though
they're not subscribed to our devel list.

Things are being tracked in this bug:
  http://dev.laptop.org/ticket/118

GCC
===

The original rationale and patch by Vladimir Makarov is here:
  http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00452.html

And it has already been debated here last year:
  http://mailman.laptop.org/pipermail/devel/2006-August/001232.html

I've backported AMD's geode patches from GCC's trunk to
4.2 and I'm currently regtesting them for inclusion in
the 4.2-branch.  I'm afraid we won't be allowed to
backport them to 4.1 too, because that branch is only
open to fixes addressing serious regressions.

Anyway, we could ask Jakub to add the Geode patches
to F7's GCC package as it's they won't impact other
architectures, so they're pretty safe.


glibc
=====

Optimized routines and benchmark results are here:
  http://dev.laptop.org/git.do?p=geode-perf;a=tree

I talked about it with Rob Savoye, who has been porting
this work with glibc.  Patches are due soon, and I will
push them to the glibc maintainers because Rob will be
away for a few days.

Glibc 2.6 has been released recently and F7 is shipping
it.  Of course we don't want to wait a full release
cycle of both projects, so we're going to patch either
our glibc RPM or preferably Fedora's.

Building custom packages
========================

I talked about it shortly with Chris Blizzard and,
of course, he'd rather try to avoid things such as
rebuilding all packages with custom GCC flags or
adding yet another sub-arch along with i386, i586
and i686.

We don't have the numbers yet, but we'll most probably
need to custom-build at least glibc.  Other candidates
include openssl, the X server, python and maybe cairo.

I'm not sure how much burden would originate from
this in our build infrastructure.  If we install a
custom GCC package configured with "--with-arch=geode",
we wouldn't need to tweak spec files or Makefiles,
at least in most cases.  But anyway, we'd have to
rename the packages because calling them something
like "xyzzy.i386.rpm" while they're actually for
the Geode would be criminal at least.

Then there's also this fine problem to be addressed:
  http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00452.html
  http://sourceware.org/ml/binutils/2006-07/msg00360.html

I've discussed it with Jordan Crouse and the bottom line
is that, basically, building for i686 on the Geode could
be dangerous because it doesn't support the NOPL opcode
that GAS could use and for other minor differences that
may bite us in the future.

As of build 428, we're still shipping with i686 versions
of glibc and openssl.  For safety, these should either
be downgraded to i586 or replaced by the Geode specific
versions.

-- 
   // Bernardo Innocenti
 \X/  http://www.codewiz.org/