Why does gcc produce an unnecessary `nop' instruction?

Why does gcc produce an unnecessary `nop' instruction?

[PRC]

Here is my code:
-----------------------------------------------
void loadicon(void)
{
	static unsigned char icon_buf[] = {
		#include "icon1.dat"
		#include "icon2.dat"
	};
	SetBufAddr(icon_buf);
}
-----------------------------------------------
And I compile it with sde-gcc ( Version 6.06 ) with options -O2 -mips32r2


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.


And I try another compiler mips-elf-gcc, and get
-----------------------------------------------
800650c0 <loadicon>:
800650c0:	3c048006 	lui	a0,0x8006
800650c4:	0801963b 	j	800658ec <SetBufAddr>
800650c8:	248460e8 	addiu	a0,a0,24808
-----------------------------------------------
There is no any more `nop'.

The gcc core of sde-gcc is 3.4.4, newer than that of mips-elf-gcc which is 3.4.0.

Based on what reasons the new gcc code produces an `nop' ?

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

[Ian Lance Taylor]

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

Ian

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

[PRC]

I look at the `objdump'ed assembly file again and I find that all functions
start at the address which is 8-byte aligned. 
Is there a particular good reason for 8-byte alignment, even if the target ARCH
is 32-bit rather than 64-bit and aligment is quite a little waste of storage and 
runtime memory?

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

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

[John Love-Jensen]

Hi PRC,

> Is there a particular good reason for 8-byte alignment, even if the target
ARCH is 32-bit rather than 64-bit and aligment is quite a little waste of
storage and runtime memory?

Perhaps your platform supports 64-bit floating point, and that entails
alignment requirements?

Sometimes the "requirements" are performance related (e.g. Intel), sometimes
they avoid SIGBUS but can be "faked" with a sigtrap to handle misalignment
(such as what could be done on the DEC Alpha), sometimes they are really
hard requirements such as MMX/SSE or AltiVec.

Hard to say without looking at the config file for your particular platform.

Sincerely,
--Eljay

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

[Ian Lance Taylor]

"PRC" <panruochen@gmail.com> writes:

> >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.
> 
> I look at the `objdump'ed assembly file again and I find that all functions
> start at the address which is 8-byte aligned. 
> Is there a particular good reason for 8-byte alignment, even if the target ARCH
> is 32-bit rather than 64-bit and aligment is quite a little waste of storage and 
> runtime memory?

Assuming you haven't used the -falign-functions option, then they are
probably being aligned so that they start on cache line boundaries.  I
don't see any code in the ARC backend to do this, so I'm not sure
where it is coming from.

Ian

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

[Darryl Miles]

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

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

[Ian Lance Taylor]

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