[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