[PATCH] powerpc: Optimise the 64bit optimised __clear_user

[Michael Ellerman]

On Thu, 2012-06-07 at 16:12 +1000, Michael Neuling wrote:
> Michael Ellerman <michael at ellerman.id.au> wrote:
> 
> > On Thu, 2012-06-07 at 16:05 +1000, Michael Neuling wrote:
> > > Benjamin Herrenschmidt <benh at kernel.crashing.org> wrote:
> > > 
> > > > On Wed, 2012-06-06 at 18:40 +0200, Segher Boessenkool wrote:
> > > > > > +err1;	dcbz	r0,r3
> > > > > 
> > > > > There is no such instruction, you probably meant "dcbz 0,r3"?
> > > > 
> > > > This reminds me... what would happen if we changed all our
> > > > 
> > > > #define	r0	0
> > > > #define	r1	1
> > > > 
> > > > etc... to:
> > > > 
> > > > #define r0	%r0
> > > > #define r1	%r1
> > > > 
> > > > ?
> > > > 
> > > > I'm thinking it might help catch that sort of nasties (and some of them
> > > > can be really nasty, such as inverting mfspr/mtspr arguments, or vs ori,
> > > > etc... ). I'm sure we'd have a problem with a few macros & inline
> > > > constructs but nothing we can't fix..
> > > 
> > > One problem with this is when we construct the instructions, like using
> > > anything from ppc-opcode.h.  eg. using PPC_POPCNTB would need to go from:
> > >     PPC_POPCNTB(r3,r3) 
> > > to:
> > >     PPC_POPCNTB(3,3) 
> > 
> > #define R(x)	x
> 
> #define R(x)	(x) 
> 
> > #define PPC_POPCNTB(R(3), R(3))
> 
> Maybe, looks pretty gross but you're the maintainer! :-)

No I am not!


I agree it's fairly gross. But I'll take gross and correct over ungross
and buggy.

cheers