From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8178 invoked by alias); 18 Nov 2005 03:11:07 -0000 Received: (qmail 8163 invoked by uid 22791); 18 Nov 2005 03:11:04 -0000 Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 18 Nov 2005 03:11:04 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id 2C31D48CF4E; Thu, 17 Nov 2005 22:11:02 -0500 (EST) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 04010-01-9; Thu, 17 Nov 2005 22:11:02 -0500 (EST) Received: from [172.16.1.3] (sdsl-216-220-103-157.dsl.bway.net [216.220.103.157]) by nile.gnat.com (Postfix) with ESMTP id BA22048CF3D; Thu, 17 Nov 2005 22:11:01 -0500 (EST) In-Reply-To: <6d98145a15b3bb76c3c1fdedd2dd66fc@apple.com> References: <437BB214.1070306@codesourcery.com> <20051117011900.GA17847@redhat.com> <437BDC9E.3080608@codesourcery.com> <1132227692.24110.40.camel@pc960.cambridge.arm.com> <437D0DC7.7040509@adacore.com> <6d98145a15b3bb76c3c1fdedd2dd66fc@apple.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2CA7B63A-49A1-42E1-9DF0-DC9154E7E8CE@adacore.com> Cc: Robert Dewar , Ian Lance Taylor , Richard Earnshaw , gcc mailing list Content-Transfer-Encoding: 7bit From: Geert Bosch Subject: Re: Link-time optimzation Date: Fri, 18 Nov 2005 03:11:00 -0000 To: Dale Johannesen Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2005-11/txt/msg00821.txt.bz2 On Nov 17, 2005, at 21:33, Dale Johannesen wrote: > When I arrived at Apple around 5 years ago, I was told of some recent > measurements that showed the assembler took around 5% of the time. > Don't know if that's still accurate. Of course the speed of the > assembler > is also relevant, and our stubs and lazy pointers probably mean > Apple's > .s files are bigger than other people's. Of course, there is a reason why almost any commercial compiler writes object files directly. If you start feeding serious GCC output through IAS (the Intel assembler) on a platform like IA64, you'll find that this really doesn't work. A file that takes seconds to compile can take over an hour to assemble. GCC tries to write out assembly in a way that is unambiguous, so the exact instructions being used are known. Any platform with a "smart optimizing", assembler will run into all kinds of issues. (Think MIPS.) Many assembler features, such as decimal floating-point number conversion, are so poorly implemented that they should be avoided at all cost. Some assemblers like to do their own instruction splitting, NOP insertion and dependency detection, completely throwing off choices made by the compiler's scheduler. Then there is alignment of code labels. If there even is the slightest doubt about what exact instruction encoding the assembler will use, all bets are off here too. If you'd start from scratch and want to get everything exactly right, it seems clear that the assembly output path is far harder to implement than writing object code directly. When you know exactly what bits you want, just go and write them. However, given that all ports are implemented based on assembly output, and that many users depend on assembly output being available, changing GCC's ways will be very labor intensive unfortunately. -Geert