From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ozlabs.org (ozlabs.org [103.22.144.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3rf4Pc2YvXzDqnk for ; Tue, 28 Jun 2016 22:10:12 +1000 (AEST) In-Reply-To: To: "Naveen N. Rao" , linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, netdev@vger.kernel.org From: Michael Ellerman Cc: Matt Evans , Daniel Borkmann , Alexei Starovoitov , Denis Kirjanov , Thadeu Lima de Souza Cascardo , Paul Mackerras , "David S. Miller" , Ananth N Mavinakayanahalli Subject: Re: [PATCHv2, 2/7] ppc: bpf/jit: Fix/enhance 32-bit Load Immediate implementation Message-Id: <3rf4Pc1S8mz9sXy@ozlabs.org> Date: Tue, 28 Jun 2016 22:10:12 +1000 (AEST) List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, 2016-22-06 at 16:25:02 UTC, "Naveen N. Rao" wrote: > The existing LI32() macro can sometimes result in a sign-extended 32-bit > load that does not clear the top 32-bits properly. As an example, > loading 0x7fffffff results in the register containing > 0xffffffff7fffffff. While this does not impact classic BPF JIT > implementation (since that only uses the lower word for all operations), > we would like to share this macro between classic BPF JIT and extended > BPF JIT, wherein the entire 64-bit value in the register matters. Fix > this by first doing a shifted LI followed by ORI. > > An additional optimization is with loading values between -32768 to -1, > where we now only need a single LI. > > The new implementation now generates the same or less number of > instructions. > > Acked-by: Alexei Starovoitov > Signed-off-by: Naveen N. Rao Series applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/aaf2f7e09932a08c1287d8e4c6 cheers