Compiler optimization for Geode/Floating Point pipeline

NoiseEHC NoiseEHC at
Tue Oct 30 06:31:35 EDT 2007

My understanding is that you will not be able to achieve significant 
speed gains with FP scheduling. The Geode already has an out-of-order 
execution unit and no matter in what order you throw ops at the unit, it 
will take almost the same clocks to execute. So you can switch on 
-march=geode and shave 1% off from the length of the code and get speed 
gains because of more free cache and that's all.

What you can do:
- fix build scripts (that 1% speed gain will not hurt)
- replace double with float
- kill operations not needed (rewrite algorithms)
- replace integer divide with mul/FP/3dnow where appropriate
- put a lot of prefetch ops into the appropriate places (very important!!!)
- measure real execution times and schedule FP ops ahead of time (even 
if they will not be needed)
- use 3dnow ops (gcc does not support them) but you have to measure 
their real execution times as well
(The last 3 requires inline asm.)

If you decide to go into asm land and measure execution speeds then 
please let me know your results. What I am interested in is the latency 
of the FP/3dnow pipeline and the real execution speeds of 
PF2ID/PF2IW/FIST/FCOMI ops since there is a high chance that the geode 
databook does not match reality in that area. I would have been tested 
them but my login to a real XO stopped working.

Brian Carnes wrote:
> The developers page on the wiki
> ( mentions:
> "compiler optimization: if you are a compiler wizard, we understand that
> the Geode lacks a specific back end code scheduler, which limits
> performance, particularly FP performance. We'd love to see work go on in
> this area which would help everyone."
> What aspects of this issue/request for help are still open?  I'll go take
> a look at the OLPC build system tonight to see what is being used (late
> versions of GCC do have some Geode -mtune/-march modes), but would 
> love to
> be hooked into whatever project is addressing this
> ...Or start my own project if I'm the first to step to the plate on this
> issue.  If anyone knows any particularly lengthy floating-point dominated
> operations in the current software, let me know and we'll use them as our
> metric for improvement.
> Thanks,
>   Brian
> _______________________________________________
> Devel mailing list
> Devel at

More information about the Devel mailing list