[llvm-bugs] [Bug 48579] New: Can we vectorize calls inside nested for loops

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Dec 22 16:00:11 PST 2020


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

            Bug ID: 48579
           Summary: Can we vectorize calls inside nested for loops
           Product: new-bugs
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: hiraditya at msn.com
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org

$ ./bin/opt -S -loop-vectorize -O3 test.ll

LV: Vector loop of width 2 costs: 65.
LV: Selecting VF: 1.
LV: Vectorization is possible but not beneficial.
LV: Interleaving is not beneficial.

The program has nested loops and there is a call in the inner loop.

$ cat test.ll


```
; RUN: opt -loop-vectorize -O3 < %s
; REQUIRES: asserts
; ModuleID = 'test.ll'
target datalayout = "e-m:o-i64:64-i128:128-n32:64-S128"
target triple = "arm64-apple-ios8.0.0"

%0 = type { float, float, float, float, float, float, float, float, i32, i32,
i32, i32, i32, i32, i32, i32, i32, i32, i8, i8, i8, i8, i8, i8, i32, i32, %1,
%12, %12, %12, %16, %17, %18, %26 }
%1 = type { %2 }
%2 = type { %3 }
%3 = type { %4* }
%4 = type <{ %5, i32, [4 x i8] }>
%5 = type { %6 }
%6 = type { %7, %8 }
%7 = type { float* }
%8 = type { %9 }
%9 = type { %10, %11* }
%10 = type { [24 x i8] }
%11 = type { i32 (...)** }
%12 = type { %13 }
%13 = type { %14 }
%14 = type { %15* }
%15 = type { i32, i32, i8, float** }
%16 = type { float, float, float }
%17 = type { float, float, float, float }
%18 = type { %19 }
%19 = type { %20*, %20*, %24 }
%20 = type { %21 }
%21 = type { %22 }
%22 = type { %23* }
%23 = type { i32, i32, %4, %4 }
%24 = type { %25 }
%25 = type { %20* }
%26 = type { [1 x %27] }
%27 = type { %28, %34, %40, %52, %45, %52, %53, %12, i8, i32 }
%28 = type { [70 x %29] }
%29 = type { %30 }
%30 = type { %31 }
%31 = type { %32* }
%32 = type { float, float, float, float, float, float, float, i8, i8, i8, i32,
[4 x i8], %33 }
%33 = type { float, float, float, [4 x i8], %4 }
%34 = type { [70 x %35] }
%35 = type { %36 }
%36 = type { %37 }
%37 = type { %38* }
%38 = type <{ i32 (...)**, i32, %39, [4 x i8] }>
%39 = type { i32, i8, i32, float, i8, float }
%40 = type { [70 x %41] }
%41 = type { %42 }
%42 = type { %43 }
%43 = type { %44* }
%44 = type { float, float, float, float, i32, [16 x float] }
%45 = type { [70 x %46] }
%46 = type { %47 }
%47 = type { %48 }
%48 = type { %49* }
%49 = type { float, i32, i32, i32, i32, i32, i32, i32, i8, i8, i8, [5 x i8],
%4, %4, [2 x float*], %50*, %51* }
%50 = type { i32, i32, float, [4 x i8], %4 }
%51 = type { i32, i32, i32, float, %4 }
%52 = type { [70 x float] }
%53 = type { [70 x %54] }
%54 = type { %55 }
%55 = type { %56 }
%56 = type { %57* }
%57 = type { float, %16, %16, %58, %59, %59, i8, i8, float, float, float,
float, float, float, float }
%58 = type { float, float, float, float, float, %16, %16 }
%59 = type { float, float, float, float, float, float, float, float, float,
float }

@0 = internal global [2 x float] [float 5.000000e-01, float 5.000000e-01],
align 4
@1 = private unnamed_addr constant [3 x i8] c"Er\00", align 1
@2 = private unnamed_addr constant [68 x i8] c"allocator<T>::allocate(size_t n)
'n' exceeds maximum supported size\00", align 1
@llvm.global_ctors = appending global [0 x { i32, void ()*, i8* }]
zeroinitializer

define hidden void @foo(%0* readonly, [2 x i64]) {
  %3 = getelementptr inbounds %0, %0* %0, i64 0, i32 33, i32 0, i64 0, i32 0,
i32 0, i64 0
  %4 = getelementptr inbounds %0, %0* %0, i64 0, i32 33, i32 0, i64 0, i32 0,
i32 0, i64 70
  br label %6

; <label>:5:                                      ; preds = %6
  ret void

; <label>:6:                                      ; preds = %6, %2
  %7 = phi %29* [ %3, %2 ], [ %26, %6 ]
  %8 = getelementptr inbounds %29, %29* %7, i64 0, i32 0, i32 0, i32 0
  %9 = load %32*, %32** %8, align 8, !tbaa !5
  %10 = extractvalue [2 x i64] %1, 0
  %11 = trunc i64 %10 to i32
  %12 = lshr i64 %10, 32
  %13 = trunc i64 %12 to i32
  %14 = extractvalue [2 x i64] %1, 1
  %15 = trunc i64 %14 to i32
  %16 = getelementptr inbounds %32, %32* %9, i64 0, i32 2
  %17 = bitcast float* %16 to i32*
  store i32 %11, i32* %17, align 8, !tbaa !9
  %18 = getelementptr inbounds %32, %32* %9, i64 0, i32 3
  %19 = bitcast float* %18 to i32*
  store i32 %13, i32* %19, align 4, !tbaa !19
  %20 = getelementptr inbounds %32, %32* %9, i64 0, i32 5
  %21 = bitcast float* %20 to i32*
  store i32 %15, i32* %21, align 4, !tbaa !20
  %22 = getelementptr inbounds %32, %32* %9, i64 0, i32 7
  %23 = lshr i64 %14, 32
  %24 = and i64 %23, 1
  %25 = trunc i64 %24 to i8
  store i8 %25, i8* %22, align 4, !tbaa !21
  %26 = getelementptr inbounds %29, %29* %7, i64 1
  %27 = icmp eq %29* %26, %4
  br i1 %27, label %5, label %6
}

!llvm.module.flags = !{!0, !1, !2, !3}

!0 = !{i32 2, !"Dwarf Version", i32 2}
!1 = !{i32 2, !"Debug Info Version", i32 3}
!2 = !{i32 1, !"wchar_size", i32 4}
!3 = !{i32 7, !"PIC Level", i32 2}
!5 = !{!6, !6, i64 0}
!6 = !{!"any pointer", !7, i64 0}
!7 = !{!"omnipotent char", !8, i64 0}
!8 = !{!"Simple C++ TBAA"}
!9 = !{!10, !11, i64 8}
!10 = !{!"foo6", !11, i64 0, !11, i64 4, !11, i64 8, !11, i64 12, !11, i64 16,
!11, i64 20, !11, i64 24, !12, i64 28, !12, i64 29, !12, i64 30, !13, i64 32,
!14, i64 40}
!11 = !{!"float", !7, i64 0}
!12 = !{!"bool", !7, i64 0}
!13 = !{!"foo1", !7, i64 0}
!14 = !{!"foo2", !11, i64 0, !11, i64 4, !11, i64 8, !15, i64 16}
!15 = !{!"foo3", !16, i64 0, !18, i64 40}
!16 = !{!"foo4", !17, i64 0}
!17 = !{!"foo5"}
!18 = !{!"int", !7, i64 0}
!19 = !{!10, !11, i64 12}
!20 = !{!10, !11, i64 20}
!21 = !{!10, !12, i64 28}
```

-- 
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/20201223/21c83ad7/attachment.html>


More information about the llvm-bugs mailing list