lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 4 Sep 2016 15:16:34 +1000
From:   Julian Calaby <>
To:     SF Markus Elfring <>
Cc:     sparclinux <>,
        Adam Buchbinder <>,
        Alexei Starovoitov <>,
        Daniel Borkmann <>,
        "David S. Miller" <>,
        Rabin Vincent <>,
        LKML <>,
        kernel-janitors <>,
        Julia Lawall <>,
        Paolo Bonzini <>
Subject: Re: sparc: bpf_jit: Move four assignments in bpf_jit_compile()

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

>> 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.


Julian Calaby


Powered by blists - more mailing lists