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

[Naveen N. Rao]

On 2017/05/31 10:53AM, Nicholas Piggin wrote:
> 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.

Ah, indeed. Good catch.

- Naveen