[PATCH] powerpc: Optimize __arch_swab32 and __arch_swab16

Joakim Tjernlund joakim.tjernlund at transmode.se
Sun Sep 11 19:32:31 EST 2011


Benjamin Herrenschmidt <benh at kernel.crashing.org> wrote on 2011/09/10 11:24:39:
>
> On Fri, 2011-09-09 at 14:10 +0200, Joakim Tjernlund wrote:
> > PPC __arch_swab32 and __arch_swab16 generates non optimal code.
> > They do not schedule very well, need to copy its input register
> > and swab16 needs an extra insn to clear its upper bits.
> > Fix this with better inline ASM.
> >
> > Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund at transmode.se>
> > ---
> >  arch/powerpc/include/asm/swab.h |   28 ++++++++++++++--------------
> >  1 files changed, 14 insertions(+), 14 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/swab.h b/arch/powerpc/include/asm/swab.h
> > index c581e3e..3b9a200 100644
> > --- a/arch/powerpc/include/asm/swab.h
> > +++ b/arch/powerpc/include/asm/swab.h
> > @@ -61,25 +61,25 @@ static inline void __arch_swab32s(__u32 *addr)
> >
> >  static inline __attribute_const__ __u16 __arch_swab16(__u16 value)
> >  {
> > -   __u16 result;
> > -
> > -   __asm__("rlwimi %0,%1,8,16,23"
> > -       : "=r" (result)
> > -       : "r" (value), "0" (value >> 8));
> > -   return result;
> > +   __asm__("rlwimi %0,%0,16,0x00ff0000\n\t"
> > +      "rlwinm %0,%0,24,0x0000ffff"
> > +      : "+r"(value));
> > +   return value;
> >  }
> >  #define __arch_swab16 __arch_swab16
>
> I don't quite get the thing about needing to clear the high bits.
>
> Value is a u16 to start with, %0 is pre-filled with value >> 8 which
> won't add anything to the upper bits, neither will rlwimi, so why would
> you need to clear upper bits ?
>
> Now I do see why gcc might generate something sub-optimal here, but can
> you provide examples of asm output before/after in the patch commit ?

I did a simple test earlier like so:

unsigned short __arch_swab16(unsigned short value)
{
		 unsigned short result;

		 __asm__("rlwimi %0,%1,8,16,23"
		     : "=r" (result)
		     : "r" (value), "0" (value >> 8));
		 return result;
}

unsigned short my__arch_swab16(unsigned short value)
{
		 __asm__("rlwimi %0,%0,16,0x00ff0000\n\t"
			 "rlwinm %0,%0,24,0x0000ffff"
			 : "+r"(value));
		 return value;
}

gcc -O2 -S outputs:

	.file	"my_swab.c"
	.section	".text"
	.align 2
	.globl __arch_swab16
	.type	__arch_swab16, @function
__arch_swab16:
	mr 0,3
	srwi 3,3,8
#APP
	rlwimi 3,0,8,16,23
#NO_APP
	rlwinm 3,3,0,0xffff
	blr
	.size	__arch_swab16, .-__arch_swab16
	.align 2
	.globl my__arch_swab16
	.type	my__arch_swab16, @function
my__arch_swab16:
#APP
	rlwimi 3,3,16,0x00ff0000
	rlwinm 3,3,24,0x0000ffff
#NO_APP
	blr
	.size	my__arch_swab16, .-my__arch_swab16
	.section	.note.GNU-stack,"", at progbits
	.ident	"GCC: (GNU) 3.4.6 (Gentoo 3.4.6-r2, ssp-3.4.6-1.0, pie-8.7.9)"

However I recently installed gcc 4.5.2 to do some tests and that gives
me this instead:
	.file	"my_swab.c"
	.gnu_attribute 4, 2
	.gnu_attribute 8, 1
	.gnu_attribute 12, 2
	.section	".text"
	.align 2
	.globl __arch_swab16
	.type	__arch_swab16, @function
__arch_swab16:
	srwi 0,3,8
#APP
 # 5 "my_swab.c" 1
	rlwimi 0,3,8,16,23
 # 0 "" 2
#NO_APP
	rlwinm 3,0,0,0xffff
	blr
	.size	__arch_swab16, .-__arch_swab16
	.align 2
	.globl my__arch_swab16
	.type	my__arch_swab16, @function
my__arch_swab16:
#APP
 # 13 "my_swab.c" 1
	rlwimi 3,3,16,0x00ff0000
	rlwinm 3,3,24,0x0000ffff
 # 0 "" 2
#NO_APP
	rlwinm 3,3,0,0xffff
	blr
	.size	my__arch_swab16, .-my__arch_swab16
	.ident	"GCC: (Gentoo 4.5.2 p1.1, pie-0.4.5) 4.5.2"
	.section	.note.GNU-stack,"", at progbits

So now both versions mask off the high bits, strange.
Not sure what is going on here?

 Jocke



More information about the Linuxppc-dev mailing list