From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8331 invoked by alias); 8 Jan 2008 19:32:30 -0000 Received: (qmail 8317 invoked by uid 22791); 8 Jan 2008 19:32:29 -0000 X-Spam-Check-By: sourceware.org Received: from secure.latencyzero.com (HELO mail.latencyzero.com) (64.71.153.217) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 08 Jan 2008 19:32:12 +0000 Received: (qmail 18464 invoked from network); 8 Jan 2008 19:32:09 -0000 Received: from unknown (HELO localhost) (rmann@127.0.0.1) by 0 with ESMTPA; 8 Jan 2008 19:32:09 -0000 Message-Id: From: Rick Mann To: gcc-help@gcc.gnu.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Similar tools builds show markedly different performance? Date: Wed, 09 Jan 2008 15:44:00 -0000 X-Mailer: Apple Mail (2.915) Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2008-01/txt/msg00079.txt.bz2 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