From: Jeff Hostetler <git@jeffhostetler.com>
Date: Fri, 20 Jan 2023 19:48:58 GMT
Subject: Re: [PATCH v2] fsm-listen-darwin: combine bit operations
Message-ID: <d9873e9b-6225-169b-4829-92f069b943af@jeffhostetler.com>
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