[llvm-bugs] [Bug 37973] New: Wrong code generation for CTLZ pattern

[via llvm-bugs]

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

            Bug ID: 37973
           Summary: Wrong code generation for CTLZ pattern
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: ovmold at gmail.com
                CC: llvm-bugs at lists.llvm.org

The motivating example:

int lzcnt(int x) 
{
   int count = 0;
   while (x > 0) {
      count++;
      x = x >> 1;
   }
   return count;
}

int main()
{
   int x = 1;
   int y = lzcnt(x);
   printf("count  = %d\n", y);
   return 0;
}

This code is compiled as: clang test.c -O3 -march=core-avx2

The pattern is recognized and the output looks like: "count  = 1". This is
wrong since the number of leading zeros for x = 1 is 31. 

Inside test.ll we can see:
define dso_local i32 @main() local_unnamed_addr #1 {
entry:
  %call1 = tail call i32 (i8*, ...) @printf(i8* getelementptr inbounds 
                               ([13 x i8], [13 x i8]* @.str, i64 0, i64 0), 
                               i32 1)
  ret i32 0
}

So, in my opinion, the problem is in the result substitution (i32 1 in
@printf), this is the result of lzcnt (number of leading 1 position), and not
quantity of leading zeros.

The same example but with scanf("%d", &x) in the main function produces the
following output for 1 as input: "count  = 32". This output is also wrong.

Inside test.ll we can see:
%1 = load i32, i32* %x, align 4, !tbaa !3
%cmp4.i = icmp sgt i32 %1, 0
%2 = call i32 @llvm.ctlz.i32(i32 %1, i1 false) #5, !range !2
%3 = sub nsw i32 32, %2

Possibly it should be: %3 = sub nsw i32 31, %2

-- 
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/20180628/b62da6dd/attachment.html>