Compiler optimization for Geode

[Rob Savoye]

Brian Carnes wrote:

> Excellent.  I'll set myself up a F7 environment, and look into the
> compiler behavior and take a look at the compiler source rpms to see if it
> supports the limited SSE extensions and the two new Geode-only
> instructions.

  I had dinner the other day with an old friend and coworker from Cygnus
days, that's also a Sr GCC hacker for AMD. He says the SSE extensions
may be usable as is, and that he thought (he doesn't work on the Geode)
thinks the new instructions are in GCC svn. So it's probably worth
checking the latest GCC sources.

> My strengths are in compilers and optimization, which is why I'm trying to
> help out in this way.  If you and Rob have everything under control, or
> have a road-map in mind for the future, do please let me know.

  Cool, I was always more of a backend, cross configuration, and BSP
hacker. I think the roadmap is simply making sure the version of GCC
used for the OLPC has support for all new instructions, and GLIBC has
had coded assembler support for the heaviest used functions.

> Great.  Shall I take the src.rpms on the gnashdev.org wiki as
> incorporating the latest version of your hand coded asm?  Or are your
> patches available somewhere else?

 The src RPM is the up to date version. I also have a version of
strcpy.S with a weird problem that is fully debugged yet. It's not part
of the snapshot.

> Someone else suggested web page rendering as a metric.  I'll see about
> instrumenting the browser to give us accurate timings for page draws under
> a debug flag.  We can then test out different apps and libraries on local
> html (including a decent amount of graphics) to see if the improvement is
> noticeable.

  The only problem with using browsing as a metric is net latency may
make the improvements hard to notice. I think I'd try something like an
animation in Gnash of Sqeak or Etoys.

> Very much agreed.  This was in response to info from Rob about issues with
> getting his own glibc builds to work with the modified compiler, and
> issues with getting a private instance of Koji working well.

 I haven't tried with Koji, it's hard enough as it is. Minor changes
have a tendency to break things completely.

> Is the OLPC build system in a state where we can request it to build a
> custom glibc (with your inline asm patches) with a custom gcc?  Or do we
> need some sort of private build system for this effort in the meantime?

  With my changes, you can rebuild glibc from the spec file. GCC will
use whichever glibc is installed.

	- rob -