[RFC][PATCH] powerpc/64s: stop using r14 register

[Nicholas Piggin]

On Wed, 31 May 2017 00:38:17 +0530
"Naveen N. Rao" <naveen.n.rao at linux.vnet.ibm.com> wrote:

> On 2017/05/22 12:00AM, Nicholas Piggin wrote:
> > I'd like to take over the r14 register for use as a per-cpu kernel
> > register similar to the way r13 is used for the paca.
> > 
> > r14 being the last non-volatile register gcc allocates, appears with
> > about 0.5% the frequency as r31 in (static) instructions. I haven't
> > counted dynamically how many extra spills and fills that removing it
> > causes, but I should. My guess is the memory ops saved by using
> > it as a per-cpu variable will significantly outweigh the cost of
> > losing it as a general use register.
> > 
> > This part of the patch is pretty mechanical. A couple of places (prom)
> > still have to use it, and I haven't quite understood the KVM code yet.
> > 
> > Question is whether this approach seems okay, and whether we should do
> > the same for 64e.
> > 
> > Thanks,
> > Nick
> > 
> > ---  
> 
> [snip]
> 
> > diff --git a/arch/powerpc/net/bpf_jit32.h 
> > b/arch/powerpc/net/bpf_jit32.h
> > index a8cd7e289ecd..52a30db033c1 100644
> > --- a/arch/powerpc/net/bpf_jit32.h
> > +++ b/arch/powerpc/net/bpf_jit32.h
> > @@ -44,9 +44,11 @@
> >   * A register	r4
> >   * X register	r5
> >   * addr param	r6
> > - * r7-r10	scratch
> > - * skb->data	r14
> > - * skb headlen	r15	(skb->len - skb->data_len)
> > + * scratch	r7-r8
> > + * skb headlen	r9	(skb->len - skb->data_len)
> > + * skb->data	r10
> > + * fixed regs	r13-r14
> > + * unused	r15
> >   * m[0]		r16
> >   * m[...]	...
> >   * m[15]	r31
> > @@ -58,8 +60,8 @@
> >  #define r_addr		6
> >  #define r_scratch1	7
> >  #define r_scratch2	8
> > -#define r_D		14
> > -#define r_HL		15
> > +#define r_HL		9
> > +#define r_D		10  
> 
> You'll also need changes in the JIT code itself, at least in 
> bpf_jit_build_prologue() and elsewhere -- some code expects r_D and r_HL 
> to be NVRs. It's probably easier to just choose other NVRs here...

Thanks for taking a look. We're out of non volatile registers here,
however... This is for PPC32 only by the looks, so the patch is not
required at all.

I should have looked a bit more closely.

Thanks,
Nick