From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4066 invoked by alias); 18 Nov 2005 02:33:01 -0000 Received: (qmail 4048 invoked by uid 22791); 18 Nov 2005 02:32:59 -0000 Received: from mail-out4.apple.com (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 18 Nov 2005 02:32:59 +0000 Received: from relay6.apple.com (a17-128-113-36.apple.com [17.128.113.36]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id jAI2WrWj020682; Thu, 17 Nov 2005 18:32:53 -0800 (PST) Received: from [17.219.196.90] (unknown [17.219.196.90]) by relay6.apple.com (Apple SCV relay) with ESMTP id 53D43184; Thu, 17 Nov 2005 18:32:53 -0800 (PST) In-Reply-To: <437D0DC7.7040509@adacore.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> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6d98145a15b3bb76c3c1fdedd2dd66fc@apple.com> Content-Transfer-Encoding: 7bit Cc: Ian Lance Taylor , Dale Johannesen , Richard Earnshaw , gcc mailing list From: Dale Johannesen Subject: Re: Link-time optimzation Date: Fri, 18 Nov 2005 02:33:00 -0000 To: Robert Dewar 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/msg00818.txt.bz2 On Nov 17, 2005, at 3:09 PM, Robert Dewar wrote: > Richard Earnshaw wrote: > >>> We spend a lot of time printing out the results of compilation as >>> assembly language, only to have to parse it all again in the >>> assembler. >>> > I never like arguments which have loaded words like "lot" without > quantification. Just how long *is* spent in this step, is it really > significant? 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.