[llvm-bugs] [Bug 34735] New: Wrong order of operations after X86DAG->DAG

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Sep 26 10:43:30 PDT 2017


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

            Bug ID: 34735
           Summary: Wrong order of operations after X86DAG->DAG
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: ilia.taraban at intel.com
                CC: llvm-bugs at lists.llvm.org

This test fails at with wrong answer after CodeGen Prepare and X86 DAG->DAG
Instruction Selection, Local Dynamic TLS Access Clean-up on O3:

================= nice.c ==============
int main ()
{
    unsigned int i = 0, j = 0;
    unsigned int l [100] = {0}, a [55] [100] = {0};
    for (i = 1; i < 55; i += 2) 
    {
        l[i] = 0;
        for (j = 17; j > 1; --j) 
        {
            a[i][j] = (43 + (l[j]));
            l[j] += 94;
        }
    }
    printf("res = %u\n", a[1][17]);
    return 0;
}

=======================================

>>> clang -v
clang version 6.0.0 (trunk 314206)
Target: x86_64-unknown-linux-gnu
Thread model: posix
...

>>> clang -O2 -o nice.exe nice.c
>>> ./nice.exe
res = 43
>>> clang -O3 -o nice.exe nice.c
>>> ./nice.exe
res = 137

>>> clang -O3 -o nice.exe nice.c -mllvm -opt-bisect-limit=103 && ./nice.exe
...
BISECT: running pass (102) Partially inline calls to library functions on
function (main)
BISECT: running pass (103) Scalarize Masked Memory Intrinsics on function
(main)
BISECT: NOT running pass (104) CodeGen Prepare on function (main)
BISECT: NOT running pass (105) X86 DAG->DAG Instruction Selection on function
(main)
...
res = 43
>>> clang -O3 -o nice.exe nice.c -mllvm -opt-bisect-limit=104 && ./nice.exe
...
BISECT: running pass (103) Scalarize Masked Memory Intrinsics on function
(main)
BISECT: running pass (104) CodeGen Prepare on function (main)
BISECT: NOT running pass (105) X86 DAG->DAG Instruction Selection on function
(main)
BISECT: NOT running pass (106) Local Dynamic TLS Access Clean-up on function
(main)
...
res = 137

If we look at IR before and after "X86 DAG->DAG Instruction Selection on
function" + "Local Dynamic TLS Access Clean-up", we'll see that there wrong
value is put into 17 element of array:
BEFORE:
  %14 = getelementptr i8, i8* %13, i64 68
  %15 = bitcast i8* %14 to i32*
  %16 = load i32, i32* %15, align 4, !tbaa !2; %16 = L[17]
  %17 = add i32 %16, 94
  store i32 %17, i32* %15, align 4, !tbaa !2;  L[17] += 94
  %18 = bitcast [100 x i32]* %1 to i8*
  %19 = getelementptr i8, i8* %18, i64 64
  %20 = bitcast i8* %19 to i32*
  %21 = load i32, i32* %20, align 16, !tbaa !2
  %22 = add i32 %21, 94
  store i32 %22, i32* %20, align 16, !tbaa !2
  %23 = bitcast [100 x i32]* %1 to i8*
  %24 = getelementptr i8, i8* %23, i64 60
  %25 = bitcast i8* %24 to i32*
  %26 = load i32, i32* %25, align 4, !tbaa !2
  %27 = add i32 %26, 94
  store i32 %27, i32* %25, align 4, !tbaa !2
  %28 = bitcast [100 x i32]* %1 to i8*
  %29 = getelementptr i8, i8* %28, i64 44
  %30 = bitcast i8* %29 to <4 x i32>*
  %31 = load <4 x i32>, <4 x i32>* %30, align 4, !tbaa !2
  %32 = extractelement <4 x i32> %31, i32 3
  %33 = insertelement <4 x i32> undef, i32 %32, i32 0
  %34 = insertelement <4 x i32> %33, i32 %26, i32 1
  %35 = insertelement <4 x i32> %34, i32 %21, i32 2
  %36 = insertelement <4 x i32> %35, i32 %16, i32 3;  HERE WE USE OLD L[17]

AFTER:
        %vreg30<def> = MOV32rm <fi#0>, 1, %noreg, 68, %noreg;
mem:LD4[%15](tbaa=!3)(dereferenceable) GR32:%vreg30
        %vreg31<def,tied1> = ADD32ri8 %vreg30<tied0>, 94,
%EFLAGS<imp-def,dead>; GR32:%vreg31,%vreg30
        MOV32mr <fi#0>, 1, %noreg, 68, %noreg, %vreg31<kill>;
mem:ST4[%15](tbaa=!3) GR32:%vreg31
        %vreg32<def> = MOV32rm <fi#0>, 1, %noreg, 64, %noreg;
mem:LD4[%20](align=16)(tbaa=!3)(dereferenceable) GR32:%vreg32
        %vreg33<def,tied1> = ADD32ri8 %vreg32<tied0>, 94,
%EFLAGS<imp-def,dead>; GR32:%vreg33,%vreg32
        %vreg34<def> = MOVQI2PQIrm <fi#0>, 1, %noreg, 64, %noreg;
mem:LD8[%20](align=16) VR128:%vreg34
        ; USING MODIFIED L[17]

AND IN RESULT ASM:
        movl    $0, (%rsp,%rcx,4)
        addl    $94, 68(%rsp)     # L[17] += 94
        movq    64(%rsp), %xmm3   # xmm3 = L[16], L[17]
        addl    $94, 64(%rsp)     # L[16] += 94
So after Codegen and x86DAG->DAG operations now stay in wrong order.

-- 
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/20170926/ebc5c567/attachment-0001.html>


More information about the llvm-bugs mailing list