From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18483 invoked by alias); 27 Jan 2008 00:49:43 -0000 Received: (qmail 18474 invoked by uid 22791); 27 Jan 2008 00:49:42 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 27 Jan 2008 00:49:23 +0000 Received: from zps19.corp.google.com (zps19.corp.google.com [172.25.146.19]) by smtp-out.google.com with ESMTP id m0R0nK4r030852; Sat, 26 Jan 2008 16:49:21 -0800 Received: from smtp.corp.google.com (spacemonkey3.corp.google.com [192.168.120.116]) by zps19.corp.google.com with ESMTP id m0R0nJgF001303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 26 Jan 2008 16:49:20 -0800 Received: from localhost.localdomain.google.com (adsl-76-249-168-94.dsl.pltn13.sbcglobal.net [76.249.168.94]) (authenticated bits=0) by smtp.corp.google.com (8.13.8/8.13.8) with ESMTP id m0R0nJre003433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 26 Jan 2008 16:49:19 -0800 To: Darryl Miles Cc: PRC , gcc-help Subject: Re: Why does gcc produce an unnecessary `nop' instruction? References: <200801251222137454465@gmail.com> <479B9400.4040208@netbauds.net> From: Ian Lance Taylor Date: Mon, 28 Jan 2008 12:12:00 -0000 In-Reply-To: <479B9400.4040208@netbauds.net> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes 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/msg00277.txt.bz2 Darryl Miles writes: > Ian Lance Taylor wrote: > > "PRC" writes: > > > >> The assembly code produced by gcc is: > >> ----------------------------------------------- > >> 800650b0 : > >> 800650b0: 3c048006 lui a0,0x8006 > >> 800650b4: 0801964b j 8006592c > >> 800650b8: 24846128 addiu a0,a0,24872 > >> 800650bc: 00000000 nop > >> ----------------------------------------------- > >> The `nop' instruction seems useless at all here. > > It's probably caused by requested alignment of the next function. > > Note that nop is just the value 0. > > To see whether gcc is actually generating the nop, use the > > --save-temps option when you compile, and look at the .s file. If you > > don't see the nop there, it's coming from something other than gcc. > > > My argument here is that inserting padding should be done by the > linker not by the compiler/assembler. The only thing the > compiler/assembler should provide in the object code is a padding > hint. The hint should also be graded from "weak hint" to "strong > hint" to "mandatory hint/requirement". You need to look at the .s file to see whether the nop is coming from the compiler or not. You didn't say whether you have done that or not. > Where a "weak hint" is used when no explicit padding requirement has > been set by the programmer, we're just getting the best practice > padding offer by the compiler for the architecture. At the moment > we're forced to accept this down our throats because the stupid > compiler/assembler forced "nop" instructions onto the tail of object > code, once its in .text its set in stone. So, change the compiler to do what you want. > I would go so far to say that padding between function/blocks inside > .text should also emit hint information to allow the linker to strip > and reorder code within objects. It would need to record the nature > of the padding (i.e. the reason it was inserted, > intra-function-padding, end-of-object-padding, > pre-variable-alignment-padding, post-variable-alignment-padding, > etc...). > > Maybe this information could be added to the reloc table, offset, > length, strength-of-padding, reason-of-padding. All quite a bit of work, but the source code is there if you want to do it. > At some future date it would be nice if the linker could re-order > object code and sub-blocks in object code and all variables so that > the most compact use of memory was possible, or the most compact .text > segment was possible in cases where we really do not care about the > performance hit but we do care about the overall code size. This > leads into having a runtime profiler take a look at the usage of your > application and re-order everything it can to make the memory foot > print smaller and the locality of variables/code better. Sounds good. Go for it. Ian