From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752398AbcIDFmZ (ORCPT ); Sun, 4 Sep 2016 01:42:25 -0400 Received: from mail-it0-f53.google.com ([209.85.214.53]:35430 "EHLO mail-it0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750747AbcIDFmW (ORCPT ); Sun, 4 Sep 2016 01:42:22 -0400 MIME-Version: 1.0 In-Reply-To: References: <566ABCD9.1060404@users.sourceforge.net> <2179bf7c-9878-adf7-da97-2746d5aa3d34@users.sourceforge.net> From: Julian Calaby Date: Sun, 4 Sep 2016 14:44:42 +1000 Message-ID: Subject: Re: [PATCH 2/4] sparc: bpf_jit: Move four assignments in bpf_jit_compile() To: SF Markus Elfring Cc: sparclinux , Adam Buchbinder , Alexei Starovoitov , Daniel Borkmann , "David S. Miller" , Rabin Vincent , LKML , kernel-janitors , Julia Lawall , Paolo Bonzini Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id u845gYTf025874 Hi Markus, On Sun, Sep 4, 2016 at 2:33 PM, SF Markus Elfring wrote: >>> Date: Sat, 3 Sep 2016 17:45:28 +0200 >>> >>> Move the assignments for four local variables a bit at the beginning >>> so that they will only be performed if a corresponding memory allocation >>> succeeded by this function. > … >>> @@ -362,10 +362,10 @@ do { *prog++ = BR_OPC | WDISP22(OFF); \ >>> >>> void bpf_jit_compile(struct bpf_prog *fp) >>> { >>> - unsigned int cleanup_addr, proglen, oldproglen = 0; >>> - u32 temp[8], *prog, *func, seen = 0, pass; >>> - const struct sock_filter *filter = fp->insns; >>> - int i, flen = fp->len, pc_ret0 = -1; >>> + unsigned int cleanup_addr, proglen, oldproglen; >>> + u32 temp[8], *prog, *func, seen, pass; >>> + const struct sock_filter *filter; >>> + int i, flen = fp->len, pc_ret0; >>> unsigned int *addrs; >>> void *image; >>> >>> @@ -385,6 +385,10 @@ void bpf_jit_compile(struct bpf_prog *fp) >>> } >>> cleanup_addr = proglen; /* epilogue address */ >>> image = NULL; >>> + filter = fp->insns; >>> + oldproglen = 0; >>> + pc_ret0 = -1; >>> + seen = 0; >>> for (pass = 0; pass < 10; pass++) { >>> u8 seen_or_pass0 = (pass == 0) ? (SEEN_XREG | SEEN_DATAREF | SEEN_MEM) : seen; > … >> If you were moving the assignments on declaration onto separate lines >> at the top of the file then ok, > > I see another software design option where the transformation result might be looking > more pleasing for you again. > > >> but why all the way down here? > > * How do you think about the reason I gave in the short commit message? Does this change improve the resulting binary? I.e. does it make it smaller or faster? If it's smaller, by how much? if it's faster, measure it. Otherwise this change is useless churn - you're making the code more complicated, longer and harder to read for practically no benefit. Thanks, -- Julian Calaby Email: julian.calaby@gmail.com Profile: http://www.google.com/profiles/julian.calaby/