[llvm-bugs] [Bug 44360] New: int have_read = read (...) --- unable to deduce that "have_read >= -1"

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=44360

            Bug ID: 44360
           Summary: int have_read = read (...) --- unable to deduce that
                    "have_read >= -1"
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C
          Assignee: unassignedclangbugs at nondot.org
          Reporter: safinaskar at mail.ru
                CC: blitzrakete at gmail.com, dgregor at apple.com,
                    erik.pilkington at gmail.com, llvm-bugs at lists.llvm.org,
                    richard-llvm at metafoo.co.uk

Here is my attempt to write fast implementation of "wc -l":

----
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int
main (void)
{
  const int block_size = 1024 * 1024;

  char *block = (char *)malloc (block_size);

  int result = 0;

  for (;;)
    {
      int have_read = read (0, block, block_size);

      if (have_read == -1)
        {
          abort ();
        }

      if (have_read == 0)
        {
          break;
        }

      for (int i = 0; i != have_read; ++i)
        {
          if (block[i] == '\n')
            {
              ++result;
            }
        }
    }

  printf ("%d\n", result);
}
----

I compiled this code using this command: "clang-10 -flto -O3 -x c SOURCE -o
/tmp/block"

Then I run the binary using this: "time -p /tmp/block < DATA" (DATA is video
file with size 7'551'083'315 bytes located on ext4 file system)

Time is 4.44 seconds (of course, I run test multiple times).

Then I replaced "have_read == -1" with "have_read < 0". Time is 3.41 seconds.

So, we see that compiler is unable to optimize original version. I think this
is a bug.

First: compiler should know that "read" always returns something that ">= -1".

Second: compiler should reason so: if "have_read" is negative, that we will
reach "i" overflow in inner loop eventually in "++i". But integer overflow is
UB. Thus we can assume that "have_read" is non-negative.

Also, if I keep "have_read == -1" as is, but change "int have_read" to "ssize_t
have_read", then I will get 3.41 seconds.

Also, gcc (version 6.3.0-18+deb9u1 from Debian) gives 3.38 seconds on initial
code and 3.02 seconds on initial code with ssize_t and 3.01 seconds on initial
code with "have_read < 0"

----
Debian stretch (with some packages from Debian buster), x86_64, Linux 4.19
"clang-10 -v" output:

----
clang version 10.0.0-+20191211115110+02168549172-1~exp1~20191211105657.1646 
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/6
Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/6.3.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.3.0
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0
Candidate multilib: .;@m64
Selected multilib: .;@m64
----

This is clang installed from https://apt.llvm.org

Intel Core i7, hyper-threading is disabled at BIOS level, /proc/cpuinfo reports
4 cores

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20191221/e55bdb61/attachment-0001.html>