[llvm-bugs] [Bug 36262] New: wrong code with opt -loop-rotate -licm

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Feb 7 03:18:13 PST 2018


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

            Bug ID: 36262
           Summary: wrong code with opt -loop-rotate -licm
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Loop Optimizer
          Assignee: unassignedbugs at nondot.org
          Reporter: paulsson at linux.vnet.ibm.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 19822
  --> https://bugs.llvm.org/attachment.cgi?id=19822&action=edit
opt input for test case as seen in the description

Csmith generated a program, which was later reduced by creduce into:

int a = 0, b = 0, c = 0, e = 11, f = 0, h = 0;
long d = 0;
short *g = &f;
int *i = 0;
main() {
  int *j = &b;
  for (; e; e--) {
    d = 9;
    for (; d; d--)
      *j = 8;
    *g = h;
    for (; a <= 9; a++)
      i = &h;
    j = i;
  }
  c = j;
  printf("checksum = %X\n", f);
}

The correct output is "checksum = 80000", per gcc -O0/-O1 etc.

It seems that licm / loop-rotate is doing something wrong:

bin/opt -mtriple=s390x-linux-gnu -mcpu=z13 -S -o out.opt.ll tc_licm_rotate.ll
-tbaa -sroa
bin/llc -mtriple=s390x-linux-gnu -mcpu=z13 -O0 out.opt.ll -o out.s
rm ./a.out; bin/clang -O0 -march=z13 out.s -o a.out; ./a.out                    
checksum = 80000

bin/opt -mtriple=s390x-linux-gnu -mcpu=z13 -S -o out.opt.ll tc_licm_rotate.ll
-tbaa -sroa -loop-rotate -licm
bin/llc -mtriple=s390x-linux-gnu -mcpu=z13 -O0 out.opt.ll -o out.s
rm ./a.out; bin/clang -O0 -march=z13 out.s -o a.out; ./a.out                    
checksum = 0

In particular, the store of immediate 8 to f via *g never happens.

- *g points to f throughout function

- first iteration: *g is assigned value of h, which is 0. *i is set to point to
h, as is *j, via *i.

- second iteration: *j now points to h, so h gets value 8. f, via *g, should
then also get the same value.

With loop rotation and invariant code motion, the load of @h has been hoisted
to outside the outer loop, which is then stored just to @g just once after the
loop. This must be wrong.

-- 
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/20180207/7fc911ab/attachment.html>


More information about the llvm-bugs mailing list