On Sun, 07 Jun 2020 18:02:44 -0700 Joe Perches <j...@perches.com> wrote:
> On Mon, 2020-06-08 at 00:40 +0000, Yann Collet wrote: > > Hi Vasily > > > > > > If I do understand the discussion, the question is about usage of `&` > > instead of `&&`, > > and the speculation that it might be an error. > > > > It's not an error. Unfortunately, explaining the reasoning behind this > > decision is a bit long. > > Likely better to add a comment around the use so that > another patch like this doesn't get submitted again. > > Perhaps something like: Yup. From: Joe Perches <j...@perches.com> Subject: lib/lz4/lz4_decompress.c: document deliberate use of `&' This operation was intentional, but tools such as smatch will warn that it might not have been. Link: http://lkml.kernel.org/r/3bf931c6ea0cae3e23f3485801986859851b4f04.ca...@perches.com Cc: Yann Collet <c...@fb.com> Cc: Vasily Averin <v...@virtuozzo.com> Cc: Gao Xiang <hsiang...@aol.com> Signed-off-by: Andrew Morton <a...@linux-foundation.org> --- lib/lz4/lz4_decompress.c | 3 +++ 1 file changed, 3 insertions(+) --- a/lib/lz4/lz4_decompress.c~lib-lz4-smatch-warning-in-lz4_decompress_generic +++ a/lib/lz4/lz4_decompress.c @@ -141,6 +141,9 @@ static FORCE_INLINE int LZ4_decompress_g * space in the output for those 18 bytes earlier, upon * entering the shortcut (in other words, there is a * combined check for both stages). + * + * The & in the likely() below is intentionally not && so that + * some compilers can produce better parallelized runtime code */ if ((endOnInput ? length != RUN_MASK : length <= 8) /* _
