.subsection madness

.subsection madness

[David Daney]

In atomic.h for atomic_add we have this gem:

	__asm__ __volatile__(
	"	.set	mips3					\n"
	"1:	ll	%0, %1		# atomic_add		\n"
	"	addu	%0, %2					\n"
	"	sc	%0, %1					\n"
	"	beqz	%0, 2f					\n"
	"	.subsection 2					\n"
	"2:	b	1b					\n"
	"	.previous					\n"
	"	.set	mips0					\n"


What is the purpose of the .subsection here?

It will not affect branch prediction in the beqz as nothing happens in 
.subsection 2.

For spin locks it is clear that this technique can help, but for 
atomic_add I don't think so.  To make matters worse for some code the 
subsection is going out of branch range.

David Daney

Re: .subsection madness

[Ralf Baechle]

On Fri, Aug 14, 2009 at 11:24:19AM -0700, David Daney wrote:

> In atomic.h for atomic_add we have this gem:
>
> 	__asm__ __volatile__(
> 	"	.set	mips3					\n"
> 	"1:	ll	%0, %1		# atomic_add		\n"
> 	"	addu	%0, %2					\n"
> 	"	sc	%0, %1					\n"
> 	"	beqz	%0, 2f					\n"
> 	"	.subsection 2					\n"
> 	"2:	b	1b					\n"
> 	"	.previous					\n"
> 	"	.set	mips0					\n"
>
>
> What is the purpose of the .subsection here?
>
> It will not affect branch prediction in the beqz as nothing happens in  
> .subsection 2.

I'm not following.  Most simple branch predictors will assume a backward
branch to be a loop completion branch and thus predict it as taken while
we assume that the SC instruction rarely fails no matter if spinlock,
bit or atomic operation.

It can even help on a CPU without branch prediction like the R4000 which
kills the two instruction following the delay slot for a taken branch.

> For spin locks it is clear that this technique can help, but for  
> atomic_add I don't think so.  To make matters worse for some code the  
> subsection is going out of branch range.

That problem should have be solved by building the kernel with
-ffunction-sections.  Other architectures needed -ffunction-sections for
the same reason.

  Ralf