Similar tools builds show markedly different performance?

[Rick Mann <rmann at latencyzero dot com>]

A little more information: there seems to be a difference in the  
resulting binary's floating point (which would go a long way to  
explaining what I'm seeing). The ELF built with the more recent tools  
results in this:

$ xscale-elf-readelf -h h.elf
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 61 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            ARM
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x80100000
  Start of program headers:          52 (bytes into file)
  Start of section headers:          448508 (bytes into file)
  Flags:                             0x602, has entry point, GNU  
EABI, software FP, VFP
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         1
  Size of section headers:           40 (bytes)
  Number of section headers:         25
  Section header string table index: 22


The ELF built with the older (faster) tools results in this:

$ arm-elf-readelf -h h.elf
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 61 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            ARM
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x80100000
  Start of program headers:          52 (bytes into file)
  Start of section headers:          411484 (bytes into file)
  Flags:                             0x402, has entry point, GNU  
EABI, VFP
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         1
  Size of section headers:           40 (bytes)
  Number of section headers:         26
  Section header string table index: 23

The relevant change is in the Flags: field. The new tools include  
"software FP", the old tools don't.

Now, the processor doesn't have hardware floating point, yet the code  
runs in both cases, so some kind of software floating point code is  
being emitted.

TIA,
Rick

(original post below)


> I've been building tools targeting the Marvell Xscale processor a  
> lot lately. A set of tools I build a few months ago seem to generate  
> much faster code on our target hardware than tools I built more  
> recently. There were some significant differences in the way the  
> tools were built, but it doesn't seem like that's enough to explain  
> the difference. Unfortunately, I don't remember exactly how I built  
> the older toolchain, so I'm hoping someone can help me determine  
> what it was by looking at the build result.
>
> Old tools:
>
> $ arm-elf-gcc -v
> Using built-in specs.
> Target: arm-elf
> Configured with: ../configure --prefix=/usr/local/arm3 --target=arm- 
> elf --with-newlib --with-cpu=xscale --enable-languages=c,c++
> Thread model: single
> gcc version 4.2.1
>
> $ arm-elf-ld --version
> GNU ld (GNU Binutils) 2.18
>
> How do I tell what version of newlib is installed (I think it's 1.15)?
>
> Built using a multistep process, where I first built binutils, then  
> gcc, then newlib (I don't recall if I did a stage 1 GCC build first,  
> but somehow I got it all working).
>
>
> The latest tools are slightly different, and built with a combined  
> tree build:
>
> gcc-4.2.2
> binutils-2.17
> newlib-1.15
>
> $ xscale-elf-gcc -v
> Using built-in specs.
> Target: xscale-elf
> Configured with: ../combined/configure --target=xscale-elf --disable- 
> nls --with-newlib --prefix=/usr/local/gcc-xscale-elf --disable- 
> newlib-supplied-syscalls
> Thread model: single
> gcc version 4.2.2
>
>
>
> I'm sorry I can't provide better information, but I'd really like to  
> figure this out. The code doesn't call into the standard C library,  
> but does make use of a lot of floating point code. Is it possible  
> that this code is better with the other tools (either built more  
> optimized, or generally different)? I don't know I'm just  
> speculating. It is C++ code (bouncing balls on a screen, the balls  
> are object instances).
>
> Thanks for any help!
>
> --
> Rick