File: slp-fma-loss.ll

package info (click to toggle)
llvm-toolchain-15 1%3A15.0.6-4
  • links: PTS, VCS
  • area: main
  • in suites: bookworm
  • size: 1,554,644 kB
  • sloc: cpp: 5,922,452; ansic: 1,012,136; asm: 674,362; python: 191,568; objc: 73,855; f90: 42,327; lisp: 31,913; pascal: 11,973; javascript: 10,144; sh: 9,421; perl: 7,447; ml: 5,527; awk: 3,523; makefile: 2,520; xml: 885; cs: 573; fortran: 567
file content (71 lines) | stat: -rw-r--r-- 3,311 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
; RUN: opt -slp-vectorizer -S -mcpu=core-avx2 -mtriple=x86_64-unknown-linux-gnu -slp-threshold=-2 < %s | FileCheck %s

; This test checks for a case when a horizontal reduction of floating-point
; adds may look profitable, but is not because it eliminates generation of
; floating-point FMAs that would be more profitable.

; FIXME: We generate a horizontal reduction today.

define void @hr() {
; CHECK-LABEL: @hr(
; CHECK-NEXT:    br label [[LOOP:%.*]]
; CHECK:       loop:
; CHECK-NEXT:    [[PHI0:%.*]] = phi double [ 0.000000e+00, [[TMP0:%.*]] ], [ [[OP_RDX:%.*]], [[LOOP]] ]
; CHECK-NEXT:    [[CVT0:%.*]] = uitofp i16 0 to double
; CHECK-NEXT:    [[TMP1:%.*]] = insertelement <4 x double> <double poison, double 0.000000e+00, double 0.000000e+00, double 0.000000e+00>, double [[CVT0]], i32 0
; CHECK-NEXT:    [[TMP2:%.*]] = fmul fast <4 x double> zeroinitializer, [[TMP1]]
; CHECK-NEXT:    [[TMP3:%.*]] = call fast double @llvm.vector.reduce.fadd.v4f64(double -0.000000e+00, <4 x double> [[TMP2]])
; CHECK-NEXT:    [[OP_RDX]] = fadd fast double [[TMP3]], [[PHI0]]
; CHECK-NEXT:    br i1 true, label [[EXIT:%.*]], label [[LOOP]]
; CHECK:       exit:
; CHECK-NEXT:    ret void
;
  br label %loop

loop:
  %phi0 = phi double [ 0.000000e+00, %0 ], [ %add3, %loop ]
  %cvt0 = uitofp i16 0 to double
  %mul0 = fmul fast double 0.000000e+00, %cvt0
  %add0 = fadd fast double %mul0, %phi0
  %mul1 = fmul fast double 0.000000e+00, 0.000000e+00
  %add1 = fadd fast double %mul1, %add0
  %mul2 = fmul fast double 0.000000e+00, 0.000000e+00
  %add2 = fadd fast double %mul2, %add1
  %mul3 = fmul fast double 0.000000e+00, 0.000000e+00
  %add3 = fadd fast double %mul3, %add2
  br i1 true, label %exit, label %loop

exit:
  ret void
}

; This test checks for a case when either a horizontal reduction of
; floating-point adds, or vectorizing a tree of floating-point multiplies,
; may look profitable; but both are not because this eliminates generation
; of floating-point FMAs that would be more profitable.

; FIXME: We generate a horizontal reduction today, and if that's disabled, we
; still vectorize some of the multiplies.

define double @hr_or_mul() {
; CHECK-LABEL: @hr_or_mul(
; CHECK-NEXT:    [[CVT0:%.*]] = uitofp i16 3 to double
; CHECK-NEXT:    [[TMP1:%.*]] = insertelement <4 x double> poison, double [[CVT0]], i32 0
; CHECK-NEXT:    [[SHUFFLE:%.*]] = shufflevector <4 x double> [[TMP1]], <4 x double> poison, <4 x i32> zeroinitializer
; CHECK-NEXT:    [[TMP2:%.*]] = fmul fast <4 x double> <double 7.000000e+00, double -4.300000e+01, double 2.200000e-02, double 9.500000e+00>, [[SHUFFLE]]
; CHECK-NEXT:    [[TMP3:%.*]] = call fast double @llvm.vector.reduce.fadd.v4f64(double -0.000000e+00, <4 x double> [[TMP2]])
; CHECK-NEXT:    [[OP_RDX:%.*]] = fadd fast double [[TMP3]], [[CVT0]]
; CHECK-NEXT:    ret double [[OP_RDX]]
;
  %cvt0 = uitofp i16 3 to double
  %mul0 = fmul fast double 7.000000e+00, %cvt0
  %add0 = fadd fast double %mul0, %cvt0
  %mul1 = fmul fast double -4.300000e+01, %cvt0
  %add1 = fadd fast double %mul1, %add0
  %mul2 = fmul fast double 2.200000e-02, %cvt0
  %add2 = fadd fast double %mul2, %add1
  %mul3 = fmul fast double 9.500000e+00, %cvt0
  %add3 = fadd fast double %mul3, %add2
  ret double %add3
}