Re: Why does gcc produce an unnecessary `nop' instruction?

[Darryl Miles <darryl-mailinglists at netbauds dot net>]

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".

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.

Where a "strong hint" is what a programmer would get if he specified a 
hint but this maybe overwritten during linking and would not cause a 
linking error to occur.

Where a "mandatory hint/requirement" is what a programmer would specify 
where the linking process must error if the padding requirement could 
not be met.


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 padding (or the minimum amount of padding) that can not be removed 
for fear of generating alignment exception is not considered padding for 
the purpose of this email.  That type of padding has a genuine purpose 
to ensure valid and correct execution at runtime.  It is only the 
extraneous padding that is inserted to improve performance can could be 
removed from the target architecture without causing runtime exceptions 
to occur.


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.


Darryl