mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Nathan Chancellor' <nathan@kernel.org>
Cc: 'Nick Terrell' <terrelln@fb.com>,
	Nick Desaulniers <ndesaulniers@google.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"llvm@lists.linux.dev" <llvm@lists.linux.dev>
Subject: RE: [PATCH] lib: zstd: Add cast to silence clang's -Wbitwise-instead-of-logical
Date: Tue, 26 Oct 2021 21:04:55 +0000	[thread overview]
Message-ID: <2c664a6701b44050a0525b541292ce21@AcuMS.aculab.com> (raw)
In-Reply-To: <YXgKgQMHQzvQgE4J@archlinux-ax161>

From: Nathan Chancellor
> Sent: 26 October 2021 15:03
...
> > Isn't enabling that warning completely stupid?
> > The casts required to silence it could easily cause more problems
> > - by hiding more important bugs. And seriously affect code readability.
> 
> Which warning?
> 
> -Wbitwise-instead-of-logical is included in clang's -Wall and I do not
> think it should be disabled; this is the first instance of the warning
> that has been silenced with a cast.

I'm not sure about that one.
I have a feeling it will generate false positives for carefully optimised
code more often that it finds anything where 'short circuiting' will
be a real gain.
Especially for values with are known to be either 0 or 1.
 
> -Wshorten-64-to-32 will never be enabled for Linux but zstd is a
> separate project that can be built for a variety of operating systems so
> that has to be considered when developing changes for the kernel because
> the kernel changes need to go upstream eventually if they touch core
> zstd code, otherwise they will just get blown away on the next import.
> Specifically, this warning was enabled on iOS:
> https://github.com/facebook/zstd/pull/2062

That one...
If you are going to enable it, then you need a static inline function
to convert u64 to u32, not a C cast.

I'm sure that it won't be long before the compiler writes start an
'open season' on casts.
They really are more dangerous than the warnings they are trying to remove.

> > ...c
> > > > index 05570ed5f8be..5105e59ac04a 100644
> > > > --- a/lib/zstd/decompress/huf_decompress.c
> > > > +++ b/lib/zstd/decompress/huf_decompress.c
> > > > @@ -886,7 +886,7 @@ HUF_decompress4X2_usingDTable_internal_body(
> > > >             HUF_DECODE_SYMBOLX2_0(op2, &bitD2);
> > > >             HUF_DECODE_SYMBOLX2_0(op3, &bitD3);
> > > >             HUF_DECODE_SYMBOLX2_0(op4, &bitD4);
> > > > -            endSignal = (U32)LIKELY(
> > > > +            endSignal = (U32)LIKELY((U32)
> > > >                         (BIT_reloadDStreamFast(&bitD1) == BIT_DStream_unfinished)
> > > >                       & (BIT_reloadDStreamFast(&bitD2) == BIT_DStream_unfinished)
> > > >                       & (BIT_reloadDStreamFast(&bitD3) == BIT_DStream_unfinished)
> >
> > Isn't that the same as:
> > 	((BIT_reload() & BIT_reload() & BIT_reload()) == BIT_DStream_unfinished)
> > which will generate much better code.
> > Especially on cpu without 'seteq' instructions.
> 
> I don't think so. Feel free to double check my math.
> 
> BIT_reloadDStreamFast() can return either BIT_DStream_unfinished (0) or
> BIT_DStream_overflow (3)....

Ah, I'd assumed that BIT_DStream_unfinished was non-zero.
So you actually want:
	endSignal = !(BIT() | BIT() | BIT());

Just kill the CaMeLs and unnecessary constants.
Then the code becomes succint, easier to read/check etc.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


  reply	other threads:[~2021-10-26 21:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-21 20:23 Nathan Chancellor
2021-10-26  1:17 ` Nick Terrell
2021-10-26 10:34   ` David Laight
2021-10-26 14:02     ` Nathan Chancellor
2021-10-26 21:04       ` David Laight [this message]
2021-11-05 21:16         ` Nick Terrell
2021-11-05 21:06   ` Nick Terrell

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2c664a6701b44050a0525b541292ce21@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=terrelln@fb.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®