From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752488AbcIDFYe (ORCPT ); Sun, 4 Sep 2016 01:24:34 -0400 Received: from mail-it0-f48.google.com ([209.85.214.48]:35001 "EHLO mail-it0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750729AbcIDFYb (ORCPT ); Sun, 4 Sep 2016 01:24:31 -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 15:16:34 +1000 Message-ID: Subject: Re: 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 Hi Markus, On Sun, Sep 4, 2016 at 3:00 PM, SF Markus Elfring wrote: >> Does this change improve the resulting binary? > > I hope so. - I propose to give the refactorings "Reduce scope of variable" > and "Extract a function" (and the corresponding consequences) another look. So you _think_ it does. Come back with real proof. I must also point out that these sorts of optimisations are things the compiler does automatically when compiling this code. Therefore it's highly likely that this change will make absolutely no difference whatsoever. (And no it won't improve compile speed in any justifiable way) >> I.e. does it make it smaller or faster? > > It is generally possible that a specific code generation variant will also affect > the run time properties you mentioned. It's _possible_? Come back with benchmarks. I must also point out that this is a "slow path" i.e. as long as it's not stupidly inefficient, the speed doesn't matter that much. This change isn't going to improve the speed of this function by any amount that matters. >> Otherwise this change is useless churn - you're making the code more >> complicated, longer and harder to read for practically no benefit. > > I imagine that there other reasons you could eventually accept > for this use case, aren't there? Unless you have some pretty damn good proof that these changes improve things, there is absolutely no reason to take them as-is - you are making the code longer and more difficult to read for no benefit and wasting everyone's time in the process. Thanks, -- Julian Calaby Email: julian.calaby@gmail.com Profile: http://www.google.com/profiles/julian.calaby/