On Wed, 31 May 2017 00:38:17 +0530
"Naveen N. Rao" [off-list ref] wrote:

On 2017/05/22 12:00AM, Nicholas Piggin wrote:

quoted

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]

quoted

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