Why does gcc produce an unnecessary `nop' instruction?

Ian Lance Taylor iant@google.com
Mon Jan 28 12:12:00 GMT 2008


Darryl Miles <darryl-mailinglists@netbauds.net> writes:

> Ian Lance Taylor wrote:
> > "PRC" <panruochen@gmail.com> writes:
> >
> >> The assembly code produced by gcc is:
> >> -----------------------------------------------
> >> 800650b0 <loadicon>:
> >> 800650b0:	3c048006 	lui	a0,0x8006
> >> 800650b4:	0801964b 	j	8006592c <SetBufAddr>
> >> 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



More information about the Gcc-help mailing list