From: Jeff Hostetler <git@jeffhostetler.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Rose via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, Seija Kijin <doremylover123@gmail.com>
Subject: Re: [PATCH v2] fsm-listen-darwin: combine bit operations
Date: Fri, 20 Jan 2023 14:48:58 -0500 [thread overview]
Message-ID: <d9873e9b-6225-169b-4829-92f069b943af@jeffhostetler.com> (raw)
In-Reply-To: <xmqqwn5hw0t5.fsf@gitster.g>
On 1/20/23 12:52 PM, Junio C Hamano wrote:
> Jeff Hostetler <git@jeffhostetler.com> writes:
>
>>> static int ef_is_dropped(const FSEventStreamEventFlags ef)
>>> {
>>> - return (ef & kFSEventStreamEventFlagMustScanSubDirs ||
>>> - ef & kFSEventStreamEventFlagKernelDropped ||
>>> - ef & kFSEventStreamEventFlagUserDropped);
>>> + return (ef & (kFSEventStreamEventFlagMustScanSubDirs |
>>> + kFSEventStreamEventFlagKernelDropped |
>>> + kFSEventStreamEventFlagUserDropped));
>>> }
>>
>> Technically, the returned value is slightly different, but
>> the only caller is just checking for non-zero, so it doesn't
>> matter.
>>
>> So this is fine.
>
> But is it worth the code churn and reviewer bandwidth? Don't we
> have better things to spend our time on?
>
> I would not be surprised if a smart enough compiler used the same
> transformartion as this patch does manually as an optimization.
>
> Then it matters more which one of the two is more readable by our
> developers. And the original matches how we humans would think, I
> would imagine. ef might have MustScanSubdirs bit, KernelDropped
> bit, or UserDropped bit and in these cases we want to say that ef is
> dropped. Arguably, the original is more readble, and it would be a
> good change to adopt if there is an upside, like the updated code
> resulting in markedly more efficient binary.
>
> So, this might be technically fine, but I am not enthused to see
> these kind of code churning patches with dubious upside. An
> optimization patch should be able to demonstrate its benefit with a
> solid benchmark, or at least a clear difference in generated code.
>
> In fact.
>
> Compiler explorer godbolt.org tells me that gcc 12 with -O2 compiles
> the following two functions into identical assembly. The !! prefix
> used in the second example is different from the postimage of what
> Seija posted, but this being a file-scope static function, I would
> expect the compiler to notice that the actual value would not matter
> to the callers, only the truth value, does.
>
>
> * Input *
> int one(unsigned int num) {
> return ((num & 01) ||
> (num & 02) || (num & 04));
> }
>
> int two(unsigned int num) {
> return !!((num) & (01|02|04));
> }
>
> * Assembly *
> one(unsigned int):
> xor eax, eax
> and edi, 7
> setne al
> ret
> two(unsigned int):
> xor eax, eax
> and edi, 7
> setne al
> ret
agreed. i didn't think the change was really worth the bother
and churn. personally, i prefer the conceptual clarity of the
code the way I wrote it.
and i was wondering if the compiler would generate the same
result, but didn't take the time (read: was too lazy) to actually
verify that.
all i was intending to say was that it wasn't a wrong change.
jeff
prev parent reply other threads:[~2023-01-20 19:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-17 21:25 [PATCH] fsm-listen-daarwin: combine bit operations Rose via GitGitGadget
2023-01-17 21:54 ` [PATCH v2] fsm-listen-darwin: " Rose via GitGitGadget
2023-01-20 15:48 ` Jeff Hostetler
2023-01-20 17:52 ` Junio C Hamano
2023-01-20 19:48 ` Jeff Hostetler [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d9873e9b-6225-169b-4829-92f069b943af@jeffhostetler.com \
--to=git@jeffhostetler.com \
--cc=doremylover123@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).