2016-11-21 23:28:21 +08:00
|
|
|
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
|
2017-02-09 22:14:06 +08:00
|
|
|
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+sse2 | FileCheck %s --check-prefix=CHECK --check-prefix=SSE --check-prefix=SSE-RECIP
|
|
|
|
|
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+avx | FileCheck %s --check-prefix=CHECK --check-prefix=AVX --check-prefix=AVX-RECIP
|
|
|
|
|
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+avx,+fma | FileCheck %s --check-prefix=CHECK --check-prefix=AVX --check-prefix=FMA-RECIP
|
2017-04-14 15:44:23 +08:00
|
|
|
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mcpu=btver2 -print-schedule | FileCheck %s --check-prefix=CHECK --check-prefix=AVX --check-prefix=BTVER2
|
|
|
|
|
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mcpu=sandybridge -print-schedule | FileCheck %s --check-prefix=CHECK --check-prefix=AVX --check-prefix=SANDY
|
|
|
|
|
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mcpu=haswell -print-schedule | FileCheck %s --check-prefix=CHECK --check-prefix=AVX --check-prefix=HASWELL
|
2017-02-09 22:14:06 +08:00
|
|
|
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mcpu=haswell -mattr=-fma | FileCheck %s --check-prefix=CHECK --check-prefix=AVX --check-prefix=HASWELL-NO-FMA
|
2017-04-14 15:44:23 +08:00
|
|
|
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mcpu=knl -print-schedule | FileCheck %s --check-prefix=CHECK --check-prefix=AVX --check-prefix=AVX512 --check-prefix=KNL
|
|
|
|
|
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mcpu=skx -print-schedule | FileCheck %s --check-prefix=CHECK --check-prefix=AVX --check-prefix=AVX512 --check-prefix=SKX
|
2014-11-12 04:51:00 +08:00
|
|
|
|
|
|
|
|
; If the target's divss/divps instructions are substantially
|
|
|
|
|
; slower than rcpss/rcpps with a Newton-Raphson refinement,
|
|
|
|
|
; we should generate the estimate sequence.
|
|
|
|
|
|
|
|
|
|
; See PR21385 ( http://llvm.org/bugs/show_bug.cgi?id=21385 )
|
|
|
|
|
; for details about the accuracy, speed, and implementation
|
|
|
|
|
; differences of x86 reciprocal estimates.
|
|
|
|
|
|
2016-10-05 04:46:43 +08:00
|
|
|
define float @f32_no_estimate(float %x) #0 {
|
2016-11-21 23:28:21 +08:00
|
|
|
; SSE-LABEL: f32_no_estimate:
|
|
|
|
|
; SSE: # BB#0:
|
|
|
|
|
; SSE-NEXT: movss {{.*#+}} xmm1 = mem[0],zero,zero,zero
|
|
|
|
|
; SSE-NEXT: divss %xmm0, %xmm1
|
|
|
|
|
; SSE-NEXT: movaps %xmm1, %xmm0
|
|
|
|
|
; SSE-NEXT: retq
|
|
|
|
|
;
|
2017-04-14 15:44:23 +08:00
|
|
|
; AVX-RECIP-LABEL: f32_no_estimate:
|
|
|
|
|
; AVX-RECIP: # BB#0:
|
|
|
|
|
; AVX-RECIP-NEXT: vmovss {{.*#+}} xmm1 = mem[0],zero,zero,zero
|
|
|
|
|
; AVX-RECIP-NEXT: vdivss %xmm0, %xmm1, %xmm0
|
|
|
|
|
; AVX-RECIP-NEXT: retq
|
|
|
|
|
;
|
|
|
|
|
; FMA-RECIP-LABEL: f32_no_estimate:
|
|
|
|
|
; FMA-RECIP: # BB#0:
|
|
|
|
|
; FMA-RECIP-NEXT: vmovss {{.*#+}} xmm1 = mem[0],zero,zero,zero
|
|
|
|
|
; FMA-RECIP-NEXT: vdivss %xmm0, %xmm1, %xmm0
|
|
|
|
|
; FMA-RECIP-NEXT: retq
|
|
|
|
|
;
|
|
|
|
|
; BTVER2-LABEL: f32_no_estimate:
|
|
|
|
|
; BTVER2: # BB#0:
|
|
|
|
|
; BTVER2-NEXT: vmovss {{.*#+}} xmm1 = mem[0],zero,zero,zero sched: [5:1.00]
|
|
|
|
|
; BTVER2-NEXT: vdivss %xmm0, %xmm1, %xmm0 # sched: [19:19.00]
|
|
|
|
|
; BTVER2-NEXT: retq # sched: [4:1.00]
|
|
|
|
|
;
|
|
|
|
|
; SANDY-LABEL: f32_no_estimate:
|
|
|
|
|
; SANDY: # BB#0:
|
This patch completely replaces the scheduling information for the SandyBridge architecture target by modifying the file X86SchedSandyBridge.td located under the X86 Target.
The SandyBridge architects have provided us with a more accurate information about each instruction latency, number of uOPs and used ports and I used it to replace the existing estimated SNB instructions scheduling and to add missing scheduling information.
Please note that the patch extensively affects the X86 MC instr scheduling for SNB.
Also note that this patch will be followed by additional patches for the remaining target architectures HSW, IVB, BDW, SKL and SKX.
The updated and extended information about each instruction includes the following details:
•static latency of the instruction
•number of uOps from which the instruction consists of
•all ports used by the instruction's' uOPs
For example, the following code dictates that instructions, ADC64mr, ADC8mr, SBB64mr, SBB8mr have a static latency of 9 cycles. Each of these instructions is decoded into 6 micro operations which use ports 4, ports 2 or 3 and port 0 and ports 0 or 1 or 5:
def SBWriteResGroup94 : SchedWriteRes<[SBPort4,SBPort23,SBPort0,SBPort015]> {
let Latency = 9;
let NumMicroOps = 6;
let ResourceCycles = [1,2,2,1];
}
def: InstRW<[SBWriteResGroup94], (instregex "ADC64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "ADC8mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB8mr")>;
Note that apart for the header, most of the X86SchedSandyBridge.td file was generated by a script.
Reviewers: zvi, chandlerc, RKSimon, m_zuckerman, craig.topper, igorb
Differential Revision: https://reviews.llvm.org/D35019#inline-304691
llvm-svn: 307529
2017-07-10 17:53:16 +08:00
|
|
|
; SANDY-NEXT: vmovss {{.*#+}} xmm1 = mem[0],zero,zero,zero sched: [6:0.50]
|
|
|
|
|
; SANDY-NEXT: vdivss %xmm0, %xmm1, %xmm0 # sched: [14:1.00]
|
|
|
|
|
; SANDY-NEXT: retq # sched: [1:1.00]
|
2017-04-14 15:44:23 +08:00
|
|
|
;
|
|
|
|
|
; HASWELL-LABEL: f32_no_estimate:
|
|
|
|
|
; HASWELL: # BB#0:
|
2017-08-28 18:04:16 +08:00
|
|
|
; HASWELL-NEXT: vmovss {{.*#+}} xmm1 = mem[0],zero,zero,zero sched: [1:0.50]
|
|
|
|
|
; HASWELL-NEXT: vdivss %xmm0, %xmm1, %xmm0 # sched: [13:1.00]
|
|
|
|
|
; HASWELL-NEXT: retq # sched: [2:1.00]
|
2017-04-14 15:44:23 +08:00
|
|
|
;
|
|
|
|
|
; HASWELL-NO-FMA-LABEL: f32_no_estimate:
|
|
|
|
|
; HASWELL-NO-FMA: # BB#0:
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vmovss {{.*#+}} xmm1 = mem[0],zero,zero,zero
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vdivss %xmm0, %xmm1, %xmm0
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: retq
|
|
|
|
|
;
|
2017-09-19 14:19:27 +08:00
|
|
|
; KNL-LABEL: f32_no_estimate:
|
|
|
|
|
; KNL: # BB#0:
|
|
|
|
|
; KNL-NEXT: vmovss {{.*#+}} xmm1 = mem[0],zero,zero,zero sched: [1:0.50]
|
|
|
|
|
; KNL-NEXT: vdivss %xmm0, %xmm1, %xmm0 # sched: [13:1.00]
|
|
|
|
|
; KNL-NEXT: retq # sched: [2:1.00]
|
|
|
|
|
;
|
|
|
|
|
; SKX-LABEL: f32_no_estimate:
|
|
|
|
|
; SKX: # BB#0:
|
|
|
|
|
; SKX-NEXT: vmovss {{.*#+}} xmm1 = mem[0],zero,zero,zero sched: [1:0.50]
|
|
|
|
|
; SKX-NEXT: vdivss %xmm0, %xmm1, %xmm0 # sched: [11:1.00]
|
|
|
|
|
; SKX-NEXT: retq # sched: [2:1.00]
|
2014-11-12 04:51:00 +08:00
|
|
|
%div = fdiv fast float 1.0, %x
|
|
|
|
|
ret float %div
|
2016-10-05 04:46:43 +08:00
|
|
|
}
|
2014-11-12 04:51:00 +08:00
|
|
|
|
2016-10-05 04:46:43 +08:00
|
|
|
define float @f32_one_step(float %x) #1 {
|
2016-11-21 23:28:21 +08:00
|
|
|
; SSE-LABEL: f32_one_step:
|
|
|
|
|
; SSE: # BB#0:
|
|
|
|
|
; SSE-NEXT: rcpss %xmm0, %xmm2
|
|
|
|
|
; SSE-NEXT: mulss %xmm2, %xmm0
|
|
|
|
|
; SSE-NEXT: movss {{.*#+}} xmm1 = mem[0],zero,zero,zero
|
|
|
|
|
; SSE-NEXT: subss %xmm0, %xmm1
|
|
|
|
|
; SSE-NEXT: mulss %xmm2, %xmm1
|
|
|
|
|
; SSE-NEXT: addss %xmm2, %xmm1
|
|
|
|
|
; SSE-NEXT: movaps %xmm1, %xmm0
|
|
|
|
|
; SSE-NEXT: retq
|
|
|
|
|
;
|
2017-02-06 02:26:17 +08:00
|
|
|
; AVX-RECIP-LABEL: f32_one_step:
|
|
|
|
|
; AVX-RECIP: # BB#0:
|
|
|
|
|
; AVX-RECIP-NEXT: vrcpss %xmm0, %xmm0, %xmm1
|
|
|
|
|
; AVX-RECIP-NEXT: vmulss %xmm1, %xmm0, %xmm0
|
|
|
|
|
; AVX-RECIP-NEXT: vmovss {{.*#+}} xmm2 = mem[0],zero,zero,zero
|
|
|
|
|
; AVX-RECIP-NEXT: vsubss %xmm0, %xmm2, %xmm0
|
|
|
|
|
; AVX-RECIP-NEXT: vmulss %xmm0, %xmm1, %xmm0
|
|
|
|
|
; AVX-RECIP-NEXT: vaddss %xmm0, %xmm1, %xmm0
|
|
|
|
|
; AVX-RECIP-NEXT: retq
|
|
|
|
|
;
|
2017-02-09 22:14:06 +08:00
|
|
|
; FMA-RECIP-LABEL: f32_one_step:
|
|
|
|
|
; FMA-RECIP: # BB#0:
|
|
|
|
|
; FMA-RECIP-NEXT: vrcpss %xmm0, %xmm0, %xmm1
|
|
|
|
|
; FMA-RECIP-NEXT: vfnmadd213ss {{.*}}(%rip), %xmm1, %xmm0
|
|
|
|
|
; FMA-RECIP-NEXT: vfmadd132ss %xmm1, %xmm1, %xmm0
|
|
|
|
|
; FMA-RECIP-NEXT: retq
|
|
|
|
|
;
|
2017-02-06 02:26:17 +08:00
|
|
|
; BTVER2-LABEL: f32_one_step:
|
|
|
|
|
; BTVER2: # BB#0:
|
2017-04-14 15:44:23 +08:00
|
|
|
; BTVER2-NEXT: vmovss {{.*#+}} xmm2 = mem[0],zero,zero,zero sched: [5:1.00]
|
|
|
|
|
; BTVER2-NEXT: vrcpss %xmm0, %xmm0, %xmm1 # sched: [2:1.00]
|
|
|
|
|
; BTVER2-NEXT: vmulss %xmm1, %xmm0, %xmm0 # sched: [2:1.00]
|
|
|
|
|
; BTVER2-NEXT: vsubss %xmm0, %xmm2, %xmm0 # sched: [3:1.00]
|
|
|
|
|
; BTVER2-NEXT: vmulss %xmm0, %xmm1, %xmm0 # sched: [2:1.00]
|
|
|
|
|
; BTVER2-NEXT: vaddss %xmm0, %xmm1, %xmm0 # sched: [3:1.00]
|
|
|
|
|
; BTVER2-NEXT: retq # sched: [4:1.00]
|
2017-02-06 02:26:17 +08:00
|
|
|
;
|
|
|
|
|
; SANDY-LABEL: f32_one_step:
|
|
|
|
|
; SANDY: # BB#0:
|
2017-04-14 15:44:23 +08:00
|
|
|
; SANDY-NEXT: vrcpss %xmm0, %xmm0, %xmm1 # sched: [5:1.00]
|
|
|
|
|
; SANDY-NEXT: vmulss %xmm1, %xmm0, %xmm0 # sched: [5:1.00]
|
This patch completely replaces the scheduling information for the SandyBridge architecture target by modifying the file X86SchedSandyBridge.td located under the X86 Target.
The SandyBridge architects have provided us with a more accurate information about each instruction latency, number of uOPs and used ports and I used it to replace the existing estimated SNB instructions scheduling and to add missing scheduling information.
Please note that the patch extensively affects the X86 MC instr scheduling for SNB.
Also note that this patch will be followed by additional patches for the remaining target architectures HSW, IVB, BDW, SKL and SKX.
The updated and extended information about each instruction includes the following details:
•static latency of the instruction
•number of uOps from which the instruction consists of
•all ports used by the instruction's' uOPs
For example, the following code dictates that instructions, ADC64mr, ADC8mr, SBB64mr, SBB8mr have a static latency of 9 cycles. Each of these instructions is decoded into 6 micro operations which use ports 4, ports 2 or 3 and port 0 and ports 0 or 1 or 5:
def SBWriteResGroup94 : SchedWriteRes<[SBPort4,SBPort23,SBPort0,SBPort015]> {
let Latency = 9;
let NumMicroOps = 6;
let ResourceCycles = [1,2,2,1];
}
def: InstRW<[SBWriteResGroup94], (instregex "ADC64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "ADC8mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB8mr")>;
Note that apart for the header, most of the X86SchedSandyBridge.td file was generated by a script.
Reviewers: zvi, chandlerc, RKSimon, m_zuckerman, craig.topper, igorb
Differential Revision: https://reviews.llvm.org/D35019#inline-304691
llvm-svn: 307529
2017-07-10 17:53:16 +08:00
|
|
|
; SANDY-NEXT: vmovss {{.*#+}} xmm2 = mem[0],zero,zero,zero sched: [6:0.50]
|
2017-04-14 15:44:23 +08:00
|
|
|
; SANDY-NEXT: vsubss %xmm0, %xmm2, %xmm0 # sched: [3:1.00]
|
|
|
|
|
; SANDY-NEXT: vmulss %xmm0, %xmm1, %xmm0 # sched: [5:1.00]
|
|
|
|
|
; SANDY-NEXT: vaddss %xmm0, %xmm1, %xmm0 # sched: [3:1.00]
|
This patch completely replaces the scheduling information for the SandyBridge architecture target by modifying the file X86SchedSandyBridge.td located under the X86 Target.
The SandyBridge architects have provided us with a more accurate information about each instruction latency, number of uOPs and used ports and I used it to replace the existing estimated SNB instructions scheduling and to add missing scheduling information.
Please note that the patch extensively affects the X86 MC instr scheduling for SNB.
Also note that this patch will be followed by additional patches for the remaining target architectures HSW, IVB, BDW, SKL and SKX.
The updated and extended information about each instruction includes the following details:
•static latency of the instruction
•number of uOps from which the instruction consists of
•all ports used by the instruction's' uOPs
For example, the following code dictates that instructions, ADC64mr, ADC8mr, SBB64mr, SBB8mr have a static latency of 9 cycles. Each of these instructions is decoded into 6 micro operations which use ports 4, ports 2 or 3 and port 0 and ports 0 or 1 or 5:
def SBWriteResGroup94 : SchedWriteRes<[SBPort4,SBPort23,SBPort0,SBPort015]> {
let Latency = 9;
let NumMicroOps = 6;
let ResourceCycles = [1,2,2,1];
}
def: InstRW<[SBWriteResGroup94], (instregex "ADC64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "ADC8mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB8mr")>;
Note that apart for the header, most of the X86SchedSandyBridge.td file was generated by a script.
Reviewers: zvi, chandlerc, RKSimon, m_zuckerman, craig.topper, igorb
Differential Revision: https://reviews.llvm.org/D35019#inline-304691
llvm-svn: 307529
2017-07-10 17:53:16 +08:00
|
|
|
; SANDY-NEXT: retq # sched: [1:1.00]
|
2017-02-06 02:26:17 +08:00
|
|
|
;
|
|
|
|
|
; HASWELL-LABEL: f32_one_step:
|
|
|
|
|
; HASWELL: # BB#0:
|
2017-04-14 15:44:23 +08:00
|
|
|
; HASWELL-NEXT: vrcpss %xmm0, %xmm0, %xmm1 # sched: [5:1.00]
|
2017-08-28 18:04:16 +08:00
|
|
|
; HASWELL-NEXT: vfnmadd213ss {{.*}}(%rip), %xmm1, %xmm0 # sched: [5:0.50]
|
|
|
|
|
; HASWELL-NEXT: vfmadd132ss %xmm1, %xmm1, %xmm0 # sched: [5:0.50]
|
|
|
|
|
; HASWELL-NEXT: retq # sched: [2:1.00]
|
2017-02-06 02:26:17 +08:00
|
|
|
;
|
2017-02-09 22:14:06 +08:00
|
|
|
; HASWELL-NO-FMA-LABEL: f32_one_step:
|
|
|
|
|
; HASWELL-NO-FMA: # BB#0:
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vrcpss %xmm0, %xmm0, %xmm1
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vmulss %xmm1, %xmm0, %xmm0
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vmovss {{.*#+}} xmm2 = mem[0],zero,zero,zero
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vsubss %xmm0, %xmm2, %xmm0
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vmulss %xmm0, %xmm1, %xmm0
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vaddss %xmm0, %xmm1, %xmm0
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: retq
|
|
|
|
|
;
|
2017-09-19 14:19:27 +08:00
|
|
|
; KNL-LABEL: f32_one_step:
|
|
|
|
|
; KNL: # BB#0:
|
|
|
|
|
; KNL-NEXT: vrcp14ss %xmm0, %xmm0, %xmm1
|
|
|
|
|
; KNL-NEXT: vfnmadd213ss {{.*}}(%rip), %xmm1, %xmm0 # sched: [5:0.50]
|
|
|
|
|
; KNL-NEXT: vfmadd132ss %xmm1, %xmm1, %xmm0 # sched: [5:0.50]
|
|
|
|
|
; KNL-NEXT: retq # sched: [2:1.00]
|
|
|
|
|
;
|
|
|
|
|
; SKX-LABEL: f32_one_step:
|
|
|
|
|
; SKX: # BB#0:
|
|
|
|
|
; SKX-NEXT: vrcp14ss %xmm0, %xmm0, %xmm1
|
|
|
|
|
; SKX-NEXT: vfnmadd213ss {{.*}}(%rip), %xmm1, %xmm0 # sched: [4:0.50]
|
|
|
|
|
; SKX-NEXT: vfmadd132ss %xmm1, %xmm1, %xmm0 # sched: [4:0.50]
|
|
|
|
|
; SKX-NEXT: retq # sched: [2:1.00]
|
2016-10-05 04:46:43 +08:00
|
|
|
%div = fdiv fast float 1.0, %x
|
|
|
|
|
ret float %div
|
|
|
|
|
}
|
2014-11-13 05:39:01 +08:00
|
|
|
|
2016-10-05 04:46:43 +08:00
|
|
|
define float @f32_two_step(float %x) #2 {
|
2016-11-21 23:28:21 +08:00
|
|
|
; SSE-LABEL: f32_two_step:
|
|
|
|
|
; SSE: # BB#0:
|
|
|
|
|
; SSE-NEXT: rcpss %xmm0, %xmm2
|
|
|
|
|
; SSE-NEXT: movaps %xmm0, %xmm3
|
|
|
|
|
; SSE-NEXT: mulss %xmm2, %xmm3
|
|
|
|
|
; SSE-NEXT: movss {{.*#+}} xmm1 = mem[0],zero,zero,zero
|
|
|
|
|
; SSE-NEXT: movaps %xmm1, %xmm4
|
|
|
|
|
; SSE-NEXT: subss %xmm3, %xmm4
|
|
|
|
|
; SSE-NEXT: mulss %xmm2, %xmm4
|
|
|
|
|
; SSE-NEXT: addss %xmm2, %xmm4
|
|
|
|
|
; SSE-NEXT: mulss %xmm4, %xmm0
|
|
|
|
|
; SSE-NEXT: subss %xmm0, %xmm1
|
|
|
|
|
; SSE-NEXT: mulss %xmm4, %xmm1
|
|
|
|
|
; SSE-NEXT: addss %xmm4, %xmm1
|
|
|
|
|
; SSE-NEXT: movaps %xmm1, %xmm0
|
|
|
|
|
; SSE-NEXT: retq
|
|
|
|
|
;
|
2017-02-06 02:26:17 +08:00
|
|
|
; AVX-RECIP-LABEL: f32_two_step:
|
|
|
|
|
; AVX-RECIP: # BB#0:
|
|
|
|
|
; AVX-RECIP-NEXT: vrcpss %xmm0, %xmm0, %xmm1
|
|
|
|
|
; AVX-RECIP-NEXT: vmulss %xmm1, %xmm0, %xmm2
|
|
|
|
|
; AVX-RECIP-NEXT: vmovss {{.*#+}} xmm3 = mem[0],zero,zero,zero
|
|
|
|
|
; AVX-RECIP-NEXT: vsubss %xmm2, %xmm3, %xmm2
|
|
|
|
|
; AVX-RECIP-NEXT: vmulss %xmm2, %xmm1, %xmm2
|
|
|
|
|
; AVX-RECIP-NEXT: vaddss %xmm2, %xmm1, %xmm1
|
|
|
|
|
; AVX-RECIP-NEXT: vmulss %xmm1, %xmm0, %xmm0
|
|
|
|
|
; AVX-RECIP-NEXT: vsubss %xmm0, %xmm3, %xmm0
|
|
|
|
|
; AVX-RECIP-NEXT: vmulss %xmm0, %xmm1, %xmm0
|
|
|
|
|
; AVX-RECIP-NEXT: vaddss %xmm0, %xmm1, %xmm0
|
|
|
|
|
; AVX-RECIP-NEXT: retq
|
|
|
|
|
;
|
2017-02-09 22:14:06 +08:00
|
|
|
; FMA-RECIP-LABEL: f32_two_step:
|
|
|
|
|
; FMA-RECIP: # BB#0:
|
|
|
|
|
; FMA-RECIP-NEXT: vrcpss %xmm0, %xmm0, %xmm1
|
|
|
|
|
; FMA-RECIP-NEXT: vmovss {{.*#+}} xmm2 = mem[0],zero,zero,zero
|
|
|
|
|
; FMA-RECIP-NEXT: vmovaps %xmm1, %xmm3
|
|
|
|
|
; FMA-RECIP-NEXT: vfnmadd213ss %xmm2, %xmm0, %xmm3
|
|
|
|
|
; FMA-RECIP-NEXT: vfmadd132ss %xmm1, %xmm1, %xmm3
|
|
|
|
|
; FMA-RECIP-NEXT: vfnmadd213ss %xmm2, %xmm3, %xmm0
|
|
|
|
|
; FMA-RECIP-NEXT: vfmadd132ss %xmm3, %xmm3, %xmm0
|
|
|
|
|
; FMA-RECIP-NEXT: retq
|
|
|
|
|
;
|
2017-02-06 02:26:17 +08:00
|
|
|
; BTVER2-LABEL: f32_two_step:
|
|
|
|
|
; BTVER2: # BB#0:
|
2017-04-14 15:44:23 +08:00
|
|
|
; BTVER2-NEXT: vmovss {{.*#+}} xmm3 = mem[0],zero,zero,zero sched: [5:1.00]
|
|
|
|
|
; BTVER2-NEXT: vrcpss %xmm0, %xmm0, %xmm1 # sched: [2:1.00]
|
|
|
|
|
; BTVER2-NEXT: vmulss %xmm1, %xmm0, %xmm2 # sched: [2:1.00]
|
|
|
|
|
; BTVER2-NEXT: vsubss %xmm2, %xmm3, %xmm2 # sched: [3:1.00]
|
|
|
|
|
; BTVER2-NEXT: vmulss %xmm2, %xmm1, %xmm2 # sched: [2:1.00]
|
|
|
|
|
; BTVER2-NEXT: vaddss %xmm2, %xmm1, %xmm1 # sched: [3:1.00]
|
|
|
|
|
; BTVER2-NEXT: vmulss %xmm1, %xmm0, %xmm0 # sched: [2:1.00]
|
|
|
|
|
; BTVER2-NEXT: vsubss %xmm0, %xmm3, %xmm0 # sched: [3:1.00]
|
|
|
|
|
; BTVER2-NEXT: vmulss %xmm0, %xmm1, %xmm0 # sched: [2:1.00]
|
|
|
|
|
; BTVER2-NEXT: vaddss %xmm0, %xmm1, %xmm0 # sched: [3:1.00]
|
|
|
|
|
; BTVER2-NEXT: retq # sched: [4:1.00]
|
2017-02-06 02:26:17 +08:00
|
|
|
;
|
|
|
|
|
; SANDY-LABEL: f32_two_step:
|
|
|
|
|
; SANDY: # BB#0:
|
2017-04-14 15:44:23 +08:00
|
|
|
; SANDY-NEXT: vrcpss %xmm0, %xmm0, %xmm1 # sched: [5:1.00]
|
|
|
|
|
; SANDY-NEXT: vmulss %xmm1, %xmm0, %xmm2 # sched: [5:1.00]
|
This patch completely replaces the scheduling information for the SandyBridge architecture target by modifying the file X86SchedSandyBridge.td located under the X86 Target.
The SandyBridge architects have provided us with a more accurate information about each instruction latency, number of uOPs and used ports and I used it to replace the existing estimated SNB instructions scheduling and to add missing scheduling information.
Please note that the patch extensively affects the X86 MC instr scheduling for SNB.
Also note that this patch will be followed by additional patches for the remaining target architectures HSW, IVB, BDW, SKL and SKX.
The updated and extended information about each instruction includes the following details:
•static latency of the instruction
•number of uOps from which the instruction consists of
•all ports used by the instruction's' uOPs
For example, the following code dictates that instructions, ADC64mr, ADC8mr, SBB64mr, SBB8mr have a static latency of 9 cycles. Each of these instructions is decoded into 6 micro operations which use ports 4, ports 2 or 3 and port 0 and ports 0 or 1 or 5:
def SBWriteResGroup94 : SchedWriteRes<[SBPort4,SBPort23,SBPort0,SBPort015]> {
let Latency = 9;
let NumMicroOps = 6;
let ResourceCycles = [1,2,2,1];
}
def: InstRW<[SBWriteResGroup94], (instregex "ADC64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "ADC8mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB8mr")>;
Note that apart for the header, most of the X86SchedSandyBridge.td file was generated by a script.
Reviewers: zvi, chandlerc, RKSimon, m_zuckerman, craig.topper, igorb
Differential Revision: https://reviews.llvm.org/D35019#inline-304691
llvm-svn: 307529
2017-07-10 17:53:16 +08:00
|
|
|
; SANDY-NEXT: vmovss {{.*#+}} xmm3 = mem[0],zero,zero,zero sched: [6:0.50]
|
2017-04-14 15:44:23 +08:00
|
|
|
; SANDY-NEXT: vsubss %xmm2, %xmm3, %xmm2 # sched: [3:1.00]
|
|
|
|
|
; SANDY-NEXT: vmulss %xmm2, %xmm1, %xmm2 # sched: [5:1.00]
|
|
|
|
|
; SANDY-NEXT: vaddss %xmm2, %xmm1, %xmm1 # sched: [3:1.00]
|
|
|
|
|
; SANDY-NEXT: vmulss %xmm1, %xmm0, %xmm0 # sched: [5:1.00]
|
|
|
|
|
; SANDY-NEXT: vsubss %xmm0, %xmm3, %xmm0 # sched: [3:1.00]
|
|
|
|
|
; SANDY-NEXT: vmulss %xmm0, %xmm1, %xmm0 # sched: [5:1.00]
|
|
|
|
|
; SANDY-NEXT: vaddss %xmm0, %xmm1, %xmm0 # sched: [3:1.00]
|
This patch completely replaces the scheduling information for the SandyBridge architecture target by modifying the file X86SchedSandyBridge.td located under the X86 Target.
The SandyBridge architects have provided us with a more accurate information about each instruction latency, number of uOPs and used ports and I used it to replace the existing estimated SNB instructions scheduling and to add missing scheduling information.
Please note that the patch extensively affects the X86 MC instr scheduling for SNB.
Also note that this patch will be followed by additional patches for the remaining target architectures HSW, IVB, BDW, SKL and SKX.
The updated and extended information about each instruction includes the following details:
•static latency of the instruction
•number of uOps from which the instruction consists of
•all ports used by the instruction's' uOPs
For example, the following code dictates that instructions, ADC64mr, ADC8mr, SBB64mr, SBB8mr have a static latency of 9 cycles. Each of these instructions is decoded into 6 micro operations which use ports 4, ports 2 or 3 and port 0 and ports 0 or 1 or 5:
def SBWriteResGroup94 : SchedWriteRes<[SBPort4,SBPort23,SBPort0,SBPort015]> {
let Latency = 9;
let NumMicroOps = 6;
let ResourceCycles = [1,2,2,1];
}
def: InstRW<[SBWriteResGroup94], (instregex "ADC64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "ADC8mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB8mr")>;
Note that apart for the header, most of the X86SchedSandyBridge.td file was generated by a script.
Reviewers: zvi, chandlerc, RKSimon, m_zuckerman, craig.topper, igorb
Differential Revision: https://reviews.llvm.org/D35019#inline-304691
llvm-svn: 307529
2017-07-10 17:53:16 +08:00
|
|
|
; SANDY-NEXT: retq # sched: [1:1.00]
|
2017-02-06 02:26:17 +08:00
|
|
|
;
|
|
|
|
|
; HASWELL-LABEL: f32_two_step:
|
|
|
|
|
; HASWELL: # BB#0:
|
2017-04-14 15:44:23 +08:00
|
|
|
; HASWELL-NEXT: vrcpss %xmm0, %xmm0, %xmm1 # sched: [5:1.00]
|
2017-08-28 18:04:16 +08:00
|
|
|
; HASWELL-NEXT: vmovss {{.*#+}} xmm2 = mem[0],zero,zero,zero sched: [1:0.50]
|
2017-04-14 15:44:23 +08:00
|
|
|
; HASWELL-NEXT: vmovaps %xmm1, %xmm3 # sched: [1:1.00]
|
2017-08-28 18:04:16 +08:00
|
|
|
; HASWELL-NEXT: vfnmadd213ss %xmm2, %xmm0, %xmm3 # sched: [5:0.50]
|
|
|
|
|
; HASWELL-NEXT: vfmadd132ss %xmm1, %xmm1, %xmm3 # sched: [5:0.50]
|
|
|
|
|
; HASWELL-NEXT: vfnmadd213ss %xmm2, %xmm3, %xmm0 # sched: [5:0.50]
|
|
|
|
|
; HASWELL-NEXT: vfmadd132ss %xmm3, %xmm3, %xmm0 # sched: [5:0.50]
|
|
|
|
|
; HASWELL-NEXT: retq # sched: [2:1.00]
|
2017-02-06 02:26:17 +08:00
|
|
|
;
|
2017-02-09 22:14:06 +08:00
|
|
|
; HASWELL-NO-FMA-LABEL: f32_two_step:
|
|
|
|
|
; HASWELL-NO-FMA: # BB#0:
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vrcpss %xmm0, %xmm0, %xmm1
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vmulss %xmm1, %xmm0, %xmm2
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vmovss {{.*#+}} xmm3 = mem[0],zero,zero,zero
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vsubss %xmm2, %xmm3, %xmm2
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vmulss %xmm2, %xmm1, %xmm2
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vaddss %xmm2, %xmm1, %xmm1
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vmulss %xmm1, %xmm0, %xmm0
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vsubss %xmm0, %xmm3, %xmm0
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vmulss %xmm0, %xmm1, %xmm0
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vaddss %xmm0, %xmm1, %xmm0
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: retq
|
|
|
|
|
;
|
2017-09-19 14:19:27 +08:00
|
|
|
; KNL-LABEL: f32_two_step:
|
|
|
|
|
; KNL: # BB#0:
|
|
|
|
|
; KNL-NEXT: vrcp14ss %xmm0, %xmm0, %xmm1
|
|
|
|
|
; KNL-NEXT: vmovss {{.*#+}} xmm2 = mem[0],zero,zero,zero sched: [1:0.50]
|
|
|
|
|
; KNL-NEXT: vmovaps %xmm1, %xmm3 # sched: [1:1.00]
|
|
|
|
|
; KNL-NEXT: vfnmadd213ss %xmm2, %xmm0, %xmm3 # sched: [5:0.50]
|
|
|
|
|
; KNL-NEXT: vfmadd132ss %xmm1, %xmm1, %xmm3 # sched: [5:0.50]
|
|
|
|
|
; KNL-NEXT: vfnmadd213ss %xmm2, %xmm3, %xmm0 # sched: [5:0.50]
|
|
|
|
|
; KNL-NEXT: vfmadd132ss %xmm3, %xmm3, %xmm0 # sched: [5:0.50]
|
|
|
|
|
; KNL-NEXT: retq # sched: [2:1.00]
|
|
|
|
|
;
|
|
|
|
|
; SKX-LABEL: f32_two_step:
|
|
|
|
|
; SKX: # BB#0:
|
|
|
|
|
; SKX-NEXT: vrcp14ss %xmm0, %xmm0, %xmm1
|
|
|
|
|
; SKX-NEXT: vmovss {{.*#+}} xmm2 = mem[0],zero,zero,zero sched: [1:0.50]
|
|
|
|
|
; SKX-NEXT: vmovaps %xmm1, %xmm3 # sched: [1:1.00]
|
|
|
|
|
; SKX-NEXT: vfnmadd213ss %xmm2, %xmm0, %xmm3 # sched: [4:0.50]
|
|
|
|
|
; SKX-NEXT: vfmadd132ss %xmm1, %xmm1, %xmm3 # sched: [4:0.50]
|
|
|
|
|
; SKX-NEXT: vfnmadd213ss %xmm2, %xmm3, %xmm0 # sched: [4:0.50]
|
|
|
|
|
; SKX-NEXT: vfmadd132ss %xmm3, %xmm3, %xmm0 # sched: [4:0.50]
|
|
|
|
|
; SKX-NEXT: retq # sched: [2:1.00]
|
2016-10-05 04:46:43 +08:00
|
|
|
%div = fdiv fast float 1.0, %x
|
|
|
|
|
ret float %div
|
2014-11-12 04:51:00 +08:00
|
|
|
}
|
|
|
|
|
|
2016-10-05 04:46:43 +08:00
|
|
|
define <4 x float> @v4f32_no_estimate(<4 x float> %x) #0 {
|
2016-11-21 23:28:21 +08:00
|
|
|
; SSE-LABEL: v4f32_no_estimate:
|
|
|
|
|
; SSE: # BB#0:
|
|
|
|
|
; SSE-NEXT: movaps {{.*#+}} xmm1 = [1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00]
|
|
|
|
|
; SSE-NEXT: divps %xmm0, %xmm1
|
|
|
|
|
; SSE-NEXT: movaps %xmm1, %xmm0
|
|
|
|
|
; SSE-NEXT: retq
|
|
|
|
|
;
|
2017-02-06 02:26:17 +08:00
|
|
|
; AVX-RECIP-LABEL: v4f32_no_estimate:
|
|
|
|
|
; AVX-RECIP: # BB#0:
|
|
|
|
|
; AVX-RECIP-NEXT: vmovaps {{.*#+}} xmm1 = [1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00]
|
|
|
|
|
; AVX-RECIP-NEXT: vdivps %xmm0, %xmm1, %xmm0
|
|
|
|
|
; AVX-RECIP-NEXT: retq
|
|
|
|
|
;
|
2017-02-09 22:14:06 +08:00
|
|
|
; FMA-RECIP-LABEL: v4f32_no_estimate:
|
|
|
|
|
; FMA-RECIP: # BB#0:
|
|
|
|
|
; FMA-RECIP-NEXT: vmovaps {{.*#+}} xmm1 = [1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00]
|
|
|
|
|
; FMA-RECIP-NEXT: vdivps %xmm0, %xmm1, %xmm0
|
|
|
|
|
; FMA-RECIP-NEXT: retq
|
|
|
|
|
;
|
2017-02-06 02:26:17 +08:00
|
|
|
; BTVER2-LABEL: v4f32_no_estimate:
|
|
|
|
|
; BTVER2: # BB#0:
|
2017-04-14 15:44:23 +08:00
|
|
|
; BTVER2-NEXT: vmovaps {{.*#+}} xmm1 = [1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00] sched: [5:1.00]
|
|
|
|
|
; BTVER2-NEXT: vdivps %xmm0, %xmm1, %xmm0 # sched: [19:19.00]
|
|
|
|
|
; BTVER2-NEXT: retq # sched: [4:1.00]
|
2017-02-06 02:26:17 +08:00
|
|
|
;
|
|
|
|
|
; SANDY-LABEL: v4f32_no_estimate:
|
|
|
|
|
; SANDY: # BB#0:
|
This patch completely replaces the scheduling information for the SandyBridge architecture target by modifying the file X86SchedSandyBridge.td located under the X86 Target.
The SandyBridge architects have provided us with a more accurate information about each instruction latency, number of uOPs and used ports and I used it to replace the existing estimated SNB instructions scheduling and to add missing scheduling information.
Please note that the patch extensively affects the X86 MC instr scheduling for SNB.
Also note that this patch will be followed by additional patches for the remaining target architectures HSW, IVB, BDW, SKL and SKX.
The updated and extended information about each instruction includes the following details:
•static latency of the instruction
•number of uOps from which the instruction consists of
•all ports used by the instruction's' uOPs
For example, the following code dictates that instructions, ADC64mr, ADC8mr, SBB64mr, SBB8mr have a static latency of 9 cycles. Each of these instructions is decoded into 6 micro operations which use ports 4, ports 2 or 3 and port 0 and ports 0 or 1 or 5:
def SBWriteResGroup94 : SchedWriteRes<[SBPort4,SBPort23,SBPort0,SBPort015]> {
let Latency = 9;
let NumMicroOps = 6;
let ResourceCycles = [1,2,2,1];
}
def: InstRW<[SBWriteResGroup94], (instregex "ADC64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "ADC8mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB8mr")>;
Note that apart for the header, most of the X86SchedSandyBridge.td file was generated by a script.
Reviewers: zvi, chandlerc, RKSimon, m_zuckerman, craig.topper, igorb
Differential Revision: https://reviews.llvm.org/D35019#inline-304691
llvm-svn: 307529
2017-07-10 17:53:16 +08:00
|
|
|
; SANDY-NEXT: vmovaps {{.*#+}} xmm1 = [1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00] sched: [6:0.50]
|
|
|
|
|
; SANDY-NEXT: vdivps %xmm0, %xmm1, %xmm0 # sched: [14:1.00]
|
|
|
|
|
; SANDY-NEXT: retq # sched: [1:1.00]
|
2017-02-06 02:26:17 +08:00
|
|
|
;
|
|
|
|
|
; HASWELL-LABEL: v4f32_no_estimate:
|
|
|
|
|
; HASWELL: # BB#0:
|
2017-08-28 18:04:16 +08:00
|
|
|
; HASWELL-NEXT: vbroadcastss {{.*#+}} xmm1 = [1,1,1,1] sched: [1:0.50]
|
|
|
|
|
; HASWELL-NEXT: vdivps %xmm0, %xmm1, %xmm0 # sched: [13:1.00]
|
|
|
|
|
; HASWELL-NEXT: retq # sched: [2:1.00]
|
2017-02-06 02:26:17 +08:00
|
|
|
;
|
2017-02-09 22:14:06 +08:00
|
|
|
; HASWELL-NO-FMA-LABEL: v4f32_no_estimate:
|
|
|
|
|
; HASWELL-NO-FMA: # BB#0:
|
2017-07-04 13:46:11 +08:00
|
|
|
; HASWELL-NO-FMA-NEXT: vbroadcastss {{.*#+}} xmm1 = [1,1,1,1]
|
2017-02-09 22:14:06 +08:00
|
|
|
; HASWELL-NO-FMA-NEXT: vdivps %xmm0, %xmm1, %xmm0
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: retq
|
|
|
|
|
;
|
2017-09-19 14:19:27 +08:00
|
|
|
; KNL-LABEL: v4f32_no_estimate:
|
|
|
|
|
; KNL: # BB#0:
|
|
|
|
|
; KNL-NEXT: vbroadcastss {{.*#+}} xmm1 = [1,1,1,1] sched: [1:0.50]
|
|
|
|
|
; KNL-NEXT: vdivps %xmm0, %xmm1, %xmm0 # sched: [13:1.00]
|
|
|
|
|
; KNL-NEXT: retq # sched: [2:1.00]
|
|
|
|
|
;
|
|
|
|
|
; SKX-LABEL: v4f32_no_estimate:
|
|
|
|
|
; SKX: # BB#0:
|
|
|
|
|
; SKX-NEXT: vbroadcastss {{.*#+}} xmm1 = [1,1,1,1] sched: [1:0.50]
|
|
|
|
|
; SKX-NEXT: vdivps %xmm0, %xmm1, %xmm0 # sched: [11:1.00]
|
|
|
|
|
; SKX-NEXT: retq # sched: [2:1.00]
|
2014-11-12 04:51:00 +08:00
|
|
|
%div = fdiv fast <4 x float> <float 1.0, float 1.0, float 1.0, float 1.0>, %x
|
|
|
|
|
ret <4 x float> %div
|
2016-10-05 04:46:43 +08:00
|
|
|
}
|
2014-11-12 04:51:00 +08:00
|
|
|
|
2016-10-05 04:46:43 +08:00
|
|
|
define <4 x float> @v4f32_one_step(<4 x float> %x) #1 {
|
2016-11-21 23:28:21 +08:00
|
|
|
; SSE-LABEL: v4f32_one_step:
|
|
|
|
|
; SSE: # BB#0:
|
|
|
|
|
; SSE-NEXT: rcpps %xmm0, %xmm2
|
|
|
|
|
; SSE-NEXT: mulps %xmm2, %xmm0
|
|
|
|
|
; SSE-NEXT: movaps {{.*#+}} xmm1 = [1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00]
|
|
|
|
|
; SSE-NEXT: subps %xmm0, %xmm1
|
|
|
|
|
; SSE-NEXT: mulps %xmm2, %xmm1
|
|
|
|
|
; SSE-NEXT: addps %xmm2, %xmm1
|
|
|
|
|
; SSE-NEXT: movaps %xmm1, %xmm0
|
|
|
|
|
; SSE-NEXT: retq
|
|
|
|
|
;
|
2017-02-06 02:26:17 +08:00
|
|
|
; AVX-RECIP-LABEL: v4f32_one_step:
|
|
|
|
|
; AVX-RECIP: # BB#0:
|
|
|
|
|
; AVX-RECIP-NEXT: vrcpps %xmm0, %xmm1
|
|
|
|
|
; AVX-RECIP-NEXT: vmulps %xmm1, %xmm0, %xmm0
|
|
|
|
|
; AVX-RECIP-NEXT: vmovaps {{.*#+}} xmm2 = [1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00]
|
|
|
|
|
; AVX-RECIP-NEXT: vsubps %xmm0, %xmm2, %xmm0
|
|
|
|
|
; AVX-RECIP-NEXT: vmulps %xmm0, %xmm1, %xmm0
|
|
|
|
|
; AVX-RECIP-NEXT: vaddps %xmm0, %xmm1, %xmm0
|
|
|
|
|
; AVX-RECIP-NEXT: retq
|
|
|
|
|
;
|
2017-02-09 22:14:06 +08:00
|
|
|
; FMA-RECIP-LABEL: v4f32_one_step:
|
|
|
|
|
; FMA-RECIP: # BB#0:
|
|
|
|
|
; FMA-RECIP-NEXT: vrcpps %xmm0, %xmm1
|
|
|
|
|
; FMA-RECIP-NEXT: vfnmadd213ps {{.*}}(%rip), %xmm1, %xmm0
|
|
|
|
|
; FMA-RECIP-NEXT: vfmadd132ps %xmm1, %xmm1, %xmm0
|
|
|
|
|
; FMA-RECIP-NEXT: retq
|
|
|
|
|
;
|
2017-02-06 02:26:17 +08:00
|
|
|
; BTVER2-LABEL: v4f32_one_step:
|
|
|
|
|
; BTVER2: # BB#0:
|
2017-04-14 15:44:23 +08:00
|
|
|
; BTVER2-NEXT: vmovaps {{.*#+}} xmm2 = [1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00] sched: [5:1.00]
|
|
|
|
|
; BTVER2-NEXT: vrcpps %xmm0, %xmm1 # sched: [2:1.00]
|
|
|
|
|
; BTVER2-NEXT: vmulps %xmm1, %xmm0, %xmm0 # sched: [2:1.00]
|
|
|
|
|
; BTVER2-NEXT: vsubps %xmm0, %xmm2, %xmm0 # sched: [3:1.00]
|
|
|
|
|
; BTVER2-NEXT: vmulps %xmm0, %xmm1, %xmm0 # sched: [2:1.00]
|
|
|
|
|
; BTVER2-NEXT: vaddps %xmm0, %xmm1, %xmm0 # sched: [3:1.00]
|
|
|
|
|
; BTVER2-NEXT: retq # sched: [4:1.00]
|
2017-02-06 02:26:17 +08:00
|
|
|
;
|
|
|
|
|
; SANDY-LABEL: v4f32_one_step:
|
|
|
|
|
; SANDY: # BB#0:
|
2017-08-13 21:59:24 +08:00
|
|
|
; SANDY-NEXT: vrcpps %xmm0, %xmm1 # sched: [5:1.00]
|
2017-04-14 15:44:23 +08:00
|
|
|
; SANDY-NEXT: vmulps %xmm1, %xmm0, %xmm0 # sched: [5:1.00]
|
This patch completely replaces the scheduling information for the SandyBridge architecture target by modifying the file X86SchedSandyBridge.td located under the X86 Target.
The SandyBridge architects have provided us with a more accurate information about each instruction latency, number of uOPs and used ports and I used it to replace the existing estimated SNB instructions scheduling and to add missing scheduling information.
Please note that the patch extensively affects the X86 MC instr scheduling for SNB.
Also note that this patch will be followed by additional patches for the remaining target architectures HSW, IVB, BDW, SKL and SKX.
The updated and extended information about each instruction includes the following details:
•static latency of the instruction
•number of uOps from which the instruction consists of
•all ports used by the instruction's' uOPs
For example, the following code dictates that instructions, ADC64mr, ADC8mr, SBB64mr, SBB8mr have a static latency of 9 cycles. Each of these instructions is decoded into 6 micro operations which use ports 4, ports 2 or 3 and port 0 and ports 0 or 1 or 5:
def SBWriteResGroup94 : SchedWriteRes<[SBPort4,SBPort23,SBPort0,SBPort015]> {
let Latency = 9;
let NumMicroOps = 6;
let ResourceCycles = [1,2,2,1];
}
def: InstRW<[SBWriteResGroup94], (instregex "ADC64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "ADC8mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB8mr")>;
Note that apart for the header, most of the X86SchedSandyBridge.td file was generated by a script.
Reviewers: zvi, chandlerc, RKSimon, m_zuckerman, craig.topper, igorb
Differential Revision: https://reviews.llvm.org/D35019#inline-304691
llvm-svn: 307529
2017-07-10 17:53:16 +08:00
|
|
|
; SANDY-NEXT: vmovaps {{.*#+}} xmm2 = [1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00] sched: [6:0.50]
|
2017-04-14 15:44:23 +08:00
|
|
|
; SANDY-NEXT: vsubps %xmm0, %xmm2, %xmm0 # sched: [3:1.00]
|
|
|
|
|
; SANDY-NEXT: vmulps %xmm0, %xmm1, %xmm0 # sched: [5:1.00]
|
|
|
|
|
; SANDY-NEXT: vaddps %xmm0, %xmm1, %xmm0 # sched: [3:1.00]
|
This patch completely replaces the scheduling information for the SandyBridge architecture target by modifying the file X86SchedSandyBridge.td located under the X86 Target.
The SandyBridge architects have provided us with a more accurate information about each instruction latency, number of uOPs and used ports and I used it to replace the existing estimated SNB instructions scheduling and to add missing scheduling information.
Please note that the patch extensively affects the X86 MC instr scheduling for SNB.
Also note that this patch will be followed by additional patches for the remaining target architectures HSW, IVB, BDW, SKL and SKX.
The updated and extended information about each instruction includes the following details:
•static latency of the instruction
•number of uOps from which the instruction consists of
•all ports used by the instruction's' uOPs
For example, the following code dictates that instructions, ADC64mr, ADC8mr, SBB64mr, SBB8mr have a static latency of 9 cycles. Each of these instructions is decoded into 6 micro operations which use ports 4, ports 2 or 3 and port 0 and ports 0 or 1 or 5:
def SBWriteResGroup94 : SchedWriteRes<[SBPort4,SBPort23,SBPort0,SBPort015]> {
let Latency = 9;
let NumMicroOps = 6;
let ResourceCycles = [1,2,2,1];
}
def: InstRW<[SBWriteResGroup94], (instregex "ADC64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "ADC8mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB8mr")>;
Note that apart for the header, most of the X86SchedSandyBridge.td file was generated by a script.
Reviewers: zvi, chandlerc, RKSimon, m_zuckerman, craig.topper, igorb
Differential Revision: https://reviews.llvm.org/D35019#inline-304691
llvm-svn: 307529
2017-07-10 17:53:16 +08:00
|
|
|
; SANDY-NEXT: retq # sched: [1:1.00]
|
2017-02-06 02:26:17 +08:00
|
|
|
;
|
|
|
|
|
; HASWELL-LABEL: v4f32_one_step:
|
|
|
|
|
; HASWELL: # BB#0:
|
2017-04-14 15:44:23 +08:00
|
|
|
; HASWELL-NEXT: vrcpps %xmm0, %xmm1 # sched: [5:1.00]
|
2017-08-28 18:04:16 +08:00
|
|
|
; HASWELL-NEXT: vbroadcastss {{.*#+}} xmm2 = [1,1,1,1] sched: [1:0.50]
|
|
|
|
|
; HASWELL-NEXT: vfnmadd213ps %xmm2, %xmm1, %xmm0 # sched: [5:0.50]
|
|
|
|
|
; HASWELL-NEXT: vfmadd132ps %xmm1, %xmm1, %xmm0 # sched: [5:0.50]
|
|
|
|
|
; HASWELL-NEXT: retq # sched: [2:1.00]
|
2017-02-06 02:26:17 +08:00
|
|
|
;
|
2017-02-09 22:14:06 +08:00
|
|
|
; HASWELL-NO-FMA-LABEL: v4f32_one_step:
|
|
|
|
|
; HASWELL-NO-FMA: # BB#0:
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vrcpps %xmm0, %xmm1
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vmulps %xmm1, %xmm0, %xmm0
|
2017-07-04 13:46:11 +08:00
|
|
|
; HASWELL-NO-FMA-NEXT: vbroadcastss {{.*#+}} xmm2 = [1,1,1,1]
|
2017-02-09 22:14:06 +08:00
|
|
|
; HASWELL-NO-FMA-NEXT: vsubps %xmm0, %xmm2, %xmm0
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vmulps %xmm0, %xmm1, %xmm0
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vaddps %xmm0, %xmm1, %xmm0
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: retq
|
|
|
|
|
;
|
2017-02-06 02:26:17 +08:00
|
|
|
; KNL-LABEL: v4f32_one_step:
|
|
|
|
|
; KNL: # BB#0:
|
2017-04-14 15:44:23 +08:00
|
|
|
; KNL-NEXT: vrcpps %xmm0, %xmm1 # sched: [5:1.00]
|
2017-08-28 18:04:16 +08:00
|
|
|
; KNL-NEXT: vbroadcastss {{.*#+}} xmm2 = [1,1,1,1] sched: [1:0.50]
|
|
|
|
|
; KNL-NEXT: vfnmadd213ps %xmm2, %xmm1, %xmm0 # sched: [5:0.50]
|
|
|
|
|
; KNL-NEXT: vfmadd132ps %xmm1, %xmm1, %xmm0 # sched: [5:0.50]
|
|
|
|
|
; KNL-NEXT: retq # sched: [2:1.00]
|
2017-02-06 02:26:17 +08:00
|
|
|
;
|
|
|
|
|
; SKX-LABEL: v4f32_one_step:
|
|
|
|
|
; SKX: # BB#0:
|
|
|
|
|
; SKX-NEXT: vrcp14ps %xmm0, %xmm1
|
|
|
|
|
; SKX-NEXT: vfnmadd213ps {{.*}}(%rip){1to4}, %xmm1, %xmm0
|
2017-09-19 14:19:27 +08:00
|
|
|
; SKX-NEXT: vfmadd132ps %xmm1, %xmm1, %xmm0 # sched: [4:0.50]
|
2017-08-28 18:04:16 +08:00
|
|
|
; SKX-NEXT: retq # sched: [2:1.00]
|
2016-10-05 04:46:43 +08:00
|
|
|
%div = fdiv fast <4 x float> <float 1.0, float 1.0, float 1.0, float 1.0>, %x
|
|
|
|
|
ret <4 x float> %div
|
|
|
|
|
}
|
2014-11-13 05:39:01 +08:00
|
|
|
|
2016-10-05 04:46:43 +08:00
|
|
|
define <4 x float> @v4f32_two_step(<4 x float> %x) #2 {
|
2016-11-21 23:28:21 +08:00
|
|
|
; SSE-LABEL: v4f32_two_step:
|
|
|
|
|
; SSE: # BB#0:
|
|
|
|
|
; SSE-NEXT: rcpps %xmm0, %xmm2
|
|
|
|
|
; SSE-NEXT: movaps %xmm0, %xmm3
|
|
|
|
|
; SSE-NEXT: mulps %xmm2, %xmm3
|
|
|
|
|
; SSE-NEXT: movaps {{.*#+}} xmm1 = [1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00]
|
|
|
|
|
; SSE-NEXT: movaps %xmm1, %xmm4
|
|
|
|
|
; SSE-NEXT: subps %xmm3, %xmm4
|
|
|
|
|
; SSE-NEXT: mulps %xmm2, %xmm4
|
|
|
|
|
; SSE-NEXT: addps %xmm2, %xmm4
|
|
|
|
|
; SSE-NEXT: mulps %xmm4, %xmm0
|
|
|
|
|
; SSE-NEXT: subps %xmm0, %xmm1
|
|
|
|
|
; SSE-NEXT: mulps %xmm4, %xmm1
|
|
|
|
|
; SSE-NEXT: addps %xmm4, %xmm1
|
|
|
|
|
; SSE-NEXT: movaps %xmm1, %xmm0
|
|
|
|
|
; SSE-NEXT: retq
|
|
|
|
|
;
|
2017-02-06 02:26:17 +08:00
|
|
|
; AVX-RECIP-LABEL: v4f32_two_step:
|
|
|
|
|
; AVX-RECIP: # BB#0:
|
|
|
|
|
; AVX-RECIP-NEXT: vrcpps %xmm0, %xmm1
|
|
|
|
|
; AVX-RECIP-NEXT: vmulps %xmm1, %xmm0, %xmm2
|
|
|
|
|
; AVX-RECIP-NEXT: vmovaps {{.*#+}} xmm3 = [1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00]
|
|
|
|
|
; AVX-RECIP-NEXT: vsubps %xmm2, %xmm3, %xmm2
|
|
|
|
|
; AVX-RECIP-NEXT: vmulps %xmm2, %xmm1, %xmm2
|
|
|
|
|
; AVX-RECIP-NEXT: vaddps %xmm2, %xmm1, %xmm1
|
|
|
|
|
; AVX-RECIP-NEXT: vmulps %xmm1, %xmm0, %xmm0
|
|
|
|
|
; AVX-RECIP-NEXT: vsubps %xmm0, %xmm3, %xmm0
|
|
|
|
|
; AVX-RECIP-NEXT: vmulps %xmm0, %xmm1, %xmm0
|
|
|
|
|
; AVX-RECIP-NEXT: vaddps %xmm0, %xmm1, %xmm0
|
|
|
|
|
; AVX-RECIP-NEXT: retq
|
|
|
|
|
;
|
2017-02-09 22:14:06 +08:00
|
|
|
; FMA-RECIP-LABEL: v4f32_two_step:
|
|
|
|
|
; FMA-RECIP: # BB#0:
|
|
|
|
|
; FMA-RECIP-NEXT: vrcpps %xmm0, %xmm1
|
|
|
|
|
; FMA-RECIP-NEXT: vmovaps {{.*#+}} xmm2 = [1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00]
|
|
|
|
|
; FMA-RECIP-NEXT: vmovaps %xmm1, %xmm3
|
|
|
|
|
; FMA-RECIP-NEXT: vfnmadd213ps %xmm2, %xmm0, %xmm3
|
|
|
|
|
; FMA-RECIP-NEXT: vfmadd132ps %xmm1, %xmm1, %xmm3
|
|
|
|
|
; FMA-RECIP-NEXT: vfnmadd213ps %xmm2, %xmm3, %xmm0
|
|
|
|
|
; FMA-RECIP-NEXT: vfmadd132ps %xmm3, %xmm3, %xmm0
|
|
|
|
|
; FMA-RECIP-NEXT: retq
|
|
|
|
|
;
|
2017-02-06 02:26:17 +08:00
|
|
|
; BTVER2-LABEL: v4f32_two_step:
|
|
|
|
|
; BTVER2: # BB#0:
|
2017-04-14 15:44:23 +08:00
|
|
|
; BTVER2-NEXT: vmovaps {{.*#+}} xmm3 = [1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00] sched: [5:1.00]
|
|
|
|
|
; BTVER2-NEXT: vrcpps %xmm0, %xmm1 # sched: [2:1.00]
|
|
|
|
|
; BTVER2-NEXT: vmulps %xmm1, %xmm0, %xmm2 # sched: [2:1.00]
|
|
|
|
|
; BTVER2-NEXT: vsubps %xmm2, %xmm3, %xmm2 # sched: [3:1.00]
|
|
|
|
|
; BTVER2-NEXT: vmulps %xmm2, %xmm1, %xmm2 # sched: [2:1.00]
|
|
|
|
|
; BTVER2-NEXT: vaddps %xmm2, %xmm1, %xmm1 # sched: [3:1.00]
|
|
|
|
|
; BTVER2-NEXT: vmulps %xmm1, %xmm0, %xmm0 # sched: [2:1.00]
|
|
|
|
|
; BTVER2-NEXT: vsubps %xmm0, %xmm3, %xmm0 # sched: [3:1.00]
|
|
|
|
|
; BTVER2-NEXT: vmulps %xmm0, %xmm1, %xmm0 # sched: [2:1.00]
|
|
|
|
|
; BTVER2-NEXT: vaddps %xmm0, %xmm1, %xmm0 # sched: [3:1.00]
|
|
|
|
|
; BTVER2-NEXT: retq # sched: [4:1.00]
|
2017-02-06 02:26:17 +08:00
|
|
|
;
|
|
|
|
|
; SANDY-LABEL: v4f32_two_step:
|
|
|
|
|
; SANDY: # BB#0:
|
2017-08-13 21:59:24 +08:00
|
|
|
; SANDY-NEXT: vrcpps %xmm0, %xmm1 # sched: [5:1.00]
|
2017-04-14 15:44:23 +08:00
|
|
|
; SANDY-NEXT: vmulps %xmm1, %xmm0, %xmm2 # sched: [5:1.00]
|
This patch completely replaces the scheduling information for the SandyBridge architecture target by modifying the file X86SchedSandyBridge.td located under the X86 Target.
The SandyBridge architects have provided us with a more accurate information about each instruction latency, number of uOPs and used ports and I used it to replace the existing estimated SNB instructions scheduling and to add missing scheduling information.
Please note that the patch extensively affects the X86 MC instr scheduling for SNB.
Also note that this patch will be followed by additional patches for the remaining target architectures HSW, IVB, BDW, SKL and SKX.
The updated and extended information about each instruction includes the following details:
•static latency of the instruction
•number of uOps from which the instruction consists of
•all ports used by the instruction's' uOPs
For example, the following code dictates that instructions, ADC64mr, ADC8mr, SBB64mr, SBB8mr have a static latency of 9 cycles. Each of these instructions is decoded into 6 micro operations which use ports 4, ports 2 or 3 and port 0 and ports 0 or 1 or 5:
def SBWriteResGroup94 : SchedWriteRes<[SBPort4,SBPort23,SBPort0,SBPort015]> {
let Latency = 9;
let NumMicroOps = 6;
let ResourceCycles = [1,2,2,1];
}
def: InstRW<[SBWriteResGroup94], (instregex "ADC64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "ADC8mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB8mr")>;
Note that apart for the header, most of the X86SchedSandyBridge.td file was generated by a script.
Reviewers: zvi, chandlerc, RKSimon, m_zuckerman, craig.topper, igorb
Differential Revision: https://reviews.llvm.org/D35019#inline-304691
llvm-svn: 307529
2017-07-10 17:53:16 +08:00
|
|
|
; SANDY-NEXT: vmovaps {{.*#+}} xmm3 = [1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00] sched: [6:0.50]
|
2017-04-14 15:44:23 +08:00
|
|
|
; SANDY-NEXT: vsubps %xmm2, %xmm3, %xmm2 # sched: [3:1.00]
|
|
|
|
|
; SANDY-NEXT: vmulps %xmm2, %xmm1, %xmm2 # sched: [5:1.00]
|
|
|
|
|
; SANDY-NEXT: vaddps %xmm2, %xmm1, %xmm1 # sched: [3:1.00]
|
|
|
|
|
; SANDY-NEXT: vmulps %xmm1, %xmm0, %xmm0 # sched: [5:1.00]
|
|
|
|
|
; SANDY-NEXT: vsubps %xmm0, %xmm3, %xmm0 # sched: [3:1.00]
|
|
|
|
|
; SANDY-NEXT: vmulps %xmm0, %xmm1, %xmm0 # sched: [5:1.00]
|
|
|
|
|
; SANDY-NEXT: vaddps %xmm0, %xmm1, %xmm0 # sched: [3:1.00]
|
This patch completely replaces the scheduling information for the SandyBridge architecture target by modifying the file X86SchedSandyBridge.td located under the X86 Target.
The SandyBridge architects have provided us with a more accurate information about each instruction latency, number of uOPs and used ports and I used it to replace the existing estimated SNB instructions scheduling and to add missing scheduling information.
Please note that the patch extensively affects the X86 MC instr scheduling for SNB.
Also note that this patch will be followed by additional patches for the remaining target architectures HSW, IVB, BDW, SKL and SKX.
The updated and extended information about each instruction includes the following details:
•static latency of the instruction
•number of uOps from which the instruction consists of
•all ports used by the instruction's' uOPs
For example, the following code dictates that instructions, ADC64mr, ADC8mr, SBB64mr, SBB8mr have a static latency of 9 cycles. Each of these instructions is decoded into 6 micro operations which use ports 4, ports 2 or 3 and port 0 and ports 0 or 1 or 5:
def SBWriteResGroup94 : SchedWriteRes<[SBPort4,SBPort23,SBPort0,SBPort015]> {
let Latency = 9;
let NumMicroOps = 6;
let ResourceCycles = [1,2,2,1];
}
def: InstRW<[SBWriteResGroup94], (instregex "ADC64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "ADC8mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB8mr")>;
Note that apart for the header, most of the X86SchedSandyBridge.td file was generated by a script.
Reviewers: zvi, chandlerc, RKSimon, m_zuckerman, craig.topper, igorb
Differential Revision: https://reviews.llvm.org/D35019#inline-304691
llvm-svn: 307529
2017-07-10 17:53:16 +08:00
|
|
|
; SANDY-NEXT: retq # sched: [1:1.00]
|
2017-02-06 02:26:17 +08:00
|
|
|
;
|
|
|
|
|
; HASWELL-LABEL: v4f32_two_step:
|
|
|
|
|
; HASWELL: # BB#0:
|
2017-04-14 15:44:23 +08:00
|
|
|
; HASWELL-NEXT: vrcpps %xmm0, %xmm1 # sched: [5:1.00]
|
2017-08-28 18:04:16 +08:00
|
|
|
; HASWELL-NEXT: vbroadcastss {{.*#+}} xmm2 = [1,1,1,1] sched: [1:0.50]
|
2017-04-14 15:44:23 +08:00
|
|
|
; HASWELL-NEXT: vmovaps %xmm1, %xmm3 # sched: [1:1.00]
|
2017-08-28 18:04:16 +08:00
|
|
|
; HASWELL-NEXT: vfnmadd213ps %xmm2, %xmm0, %xmm3 # sched: [5:0.50]
|
|
|
|
|
; HASWELL-NEXT: vfmadd132ps %xmm1, %xmm1, %xmm3 # sched: [5:0.50]
|
|
|
|
|
; HASWELL-NEXT: vfnmadd213ps %xmm2, %xmm3, %xmm0 # sched: [5:0.50]
|
|
|
|
|
; HASWELL-NEXT: vfmadd132ps %xmm3, %xmm3, %xmm0 # sched: [5:0.50]
|
|
|
|
|
; HASWELL-NEXT: retq # sched: [2:1.00]
|
2017-02-06 02:26:17 +08:00
|
|
|
;
|
2017-02-09 22:14:06 +08:00
|
|
|
; HASWELL-NO-FMA-LABEL: v4f32_two_step:
|
|
|
|
|
; HASWELL-NO-FMA: # BB#0:
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vrcpps %xmm0, %xmm1
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vmulps %xmm1, %xmm0, %xmm2
|
2017-07-04 13:46:11 +08:00
|
|
|
; HASWELL-NO-FMA-NEXT: vbroadcastss {{.*#+}} xmm3 = [1,1,1,1]
|
2017-02-09 22:14:06 +08:00
|
|
|
; HASWELL-NO-FMA-NEXT: vsubps %xmm2, %xmm3, %xmm2
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vmulps %xmm2, %xmm1, %xmm2
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vaddps %xmm2, %xmm1, %xmm1
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vmulps %xmm1, %xmm0, %xmm0
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vsubps %xmm0, %xmm3, %xmm0
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vmulps %xmm0, %xmm1, %xmm0
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vaddps %xmm0, %xmm1, %xmm0
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: retq
|
|
|
|
|
;
|
2017-02-06 02:26:17 +08:00
|
|
|
; KNL-LABEL: v4f32_two_step:
|
|
|
|
|
; KNL: # BB#0:
|
2017-04-14 15:44:23 +08:00
|
|
|
; KNL-NEXT: vrcpps %xmm0, %xmm1 # sched: [5:1.00]
|
2017-08-28 18:04:16 +08:00
|
|
|
; KNL-NEXT: vbroadcastss {{.*#+}} xmm2 = [1,1,1,1] sched: [1:0.50]
|
2017-04-14 15:44:23 +08:00
|
|
|
; KNL-NEXT: vmovaps %xmm1, %xmm3 # sched: [1:1.00]
|
2017-08-28 18:04:16 +08:00
|
|
|
; KNL-NEXT: vfnmadd213ps %xmm2, %xmm0, %xmm3 # sched: [5:0.50]
|
|
|
|
|
; KNL-NEXT: vfmadd132ps %xmm1, %xmm1, %xmm3 # sched: [5:0.50]
|
|
|
|
|
; KNL-NEXT: vfnmadd213ps %xmm2, %xmm3, %xmm0 # sched: [5:0.50]
|
|
|
|
|
; KNL-NEXT: vfmadd132ps %xmm3, %xmm3, %xmm0 # sched: [5:0.50]
|
|
|
|
|
; KNL-NEXT: retq # sched: [2:1.00]
|
2017-02-06 02:26:17 +08:00
|
|
|
;
|
|
|
|
|
; SKX-LABEL: v4f32_two_step:
|
|
|
|
|
; SKX: # BB#0:
|
|
|
|
|
; SKX-NEXT: vrcp14ps %xmm0, %xmm1
|
2017-08-28 18:04:16 +08:00
|
|
|
; SKX-NEXT: vbroadcastss {{.*#+}} xmm2 = [1,1,1,1] sched: [1:0.50]
|
2017-04-14 15:44:23 +08:00
|
|
|
; SKX-NEXT: vmovaps %xmm1, %xmm3 # sched: [1:1.00]
|
2017-09-19 14:19:27 +08:00
|
|
|
; SKX-NEXT: vfnmadd213ps %xmm2, %xmm0, %xmm3 # sched: [4:0.50]
|
|
|
|
|
; SKX-NEXT: vfmadd132ps %xmm1, %xmm1, %xmm3 # sched: [4:0.50]
|
|
|
|
|
; SKX-NEXT: vfnmadd213ps %xmm2, %xmm3, %xmm0 # sched: [4:0.50]
|
|
|
|
|
; SKX-NEXT: vfmadd132ps %xmm3, %xmm3, %xmm0 # sched: [4:0.50]
|
2017-08-28 18:04:16 +08:00
|
|
|
; SKX-NEXT: retq # sched: [2:1.00]
|
2016-10-05 04:46:43 +08:00
|
|
|
%div = fdiv fast <4 x float> <float 1.0, float 1.0, float 1.0, float 1.0>, %x
|
|
|
|
|
ret <4 x float> %div
|
2014-11-12 04:51:00 +08:00
|
|
|
}
|
|
|
|
|
|
2016-10-05 04:46:43 +08:00
|
|
|
define <8 x float> @v8f32_no_estimate(<8 x float> %x) #0 {
|
2016-11-21 23:28:21 +08:00
|
|
|
; SSE-LABEL: v8f32_no_estimate:
|
|
|
|
|
; SSE: # BB#0:
|
|
|
|
|
; SSE-NEXT: movaps {{.*#+}} xmm2 = [1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00]
|
|
|
|
|
; SSE-NEXT: movaps %xmm2, %xmm3
|
|
|
|
|
; SSE-NEXT: divps %xmm0, %xmm3
|
|
|
|
|
; SSE-NEXT: divps %xmm1, %xmm2
|
|
|
|
|
; SSE-NEXT: movaps %xmm3, %xmm0
|
|
|
|
|
; SSE-NEXT: movaps %xmm2, %xmm1
|
|
|
|
|
; SSE-NEXT: retq
|
|
|
|
|
;
|
2017-02-06 02:26:17 +08:00
|
|
|
; AVX-RECIP-LABEL: v8f32_no_estimate:
|
|
|
|
|
; AVX-RECIP: # BB#0:
|
|
|
|
|
; AVX-RECIP-NEXT: vmovaps {{.*#+}} ymm1 = [1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00]
|
|
|
|
|
; AVX-RECIP-NEXT: vdivps %ymm0, %ymm1, %ymm0
|
|
|
|
|
; AVX-RECIP-NEXT: retq
|
|
|
|
|
;
|
2017-02-09 22:14:06 +08:00
|
|
|
; FMA-RECIP-LABEL: v8f32_no_estimate:
|
|
|
|
|
; FMA-RECIP: # BB#0:
|
|
|
|
|
; FMA-RECIP-NEXT: vmovaps {{.*#+}} ymm1 = [1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00]
|
|
|
|
|
; FMA-RECIP-NEXT: vdivps %ymm0, %ymm1, %ymm0
|
|
|
|
|
; FMA-RECIP-NEXT: retq
|
|
|
|
|
;
|
2017-02-06 02:26:17 +08:00
|
|
|
; BTVER2-LABEL: v8f32_no_estimate:
|
|
|
|
|
; BTVER2: # BB#0:
|
2017-04-14 15:44:23 +08:00
|
|
|
; BTVER2-NEXT: vmovaps {{.*#+}} ymm1 = [1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00] sched: [5:1.00]
|
2017-07-11 00:36:03 +08:00
|
|
|
; BTVER2-NEXT: vdivps %ymm0, %ymm1, %ymm0 # sched: [38:38.00]
|
2017-04-14 15:44:23 +08:00
|
|
|
; BTVER2-NEXT: retq # sched: [4:1.00]
|
2017-02-06 02:26:17 +08:00
|
|
|
;
|
|
|
|
|
; SANDY-LABEL: v8f32_no_estimate:
|
|
|
|
|
; SANDY: # BB#0:
|
This patch completely replaces the scheduling information for the SandyBridge architecture target by modifying the file X86SchedSandyBridge.td located under the X86 Target.
The SandyBridge architects have provided us with a more accurate information about each instruction latency, number of uOPs and used ports and I used it to replace the existing estimated SNB instructions scheduling and to add missing scheduling information.
Please note that the patch extensively affects the X86 MC instr scheduling for SNB.
Also note that this patch will be followed by additional patches for the remaining target architectures HSW, IVB, BDW, SKL and SKX.
The updated and extended information about each instruction includes the following details:
•static latency of the instruction
•number of uOps from which the instruction consists of
•all ports used by the instruction's' uOPs
For example, the following code dictates that instructions, ADC64mr, ADC8mr, SBB64mr, SBB8mr have a static latency of 9 cycles. Each of these instructions is decoded into 6 micro operations which use ports 4, ports 2 or 3 and port 0 and ports 0 or 1 or 5:
def SBWriteResGroup94 : SchedWriteRes<[SBPort4,SBPort23,SBPort0,SBPort015]> {
let Latency = 9;
let NumMicroOps = 6;
let ResourceCycles = [1,2,2,1];
}
def: InstRW<[SBWriteResGroup94], (instregex "ADC64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "ADC8mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB8mr")>;
Note that apart for the header, most of the X86SchedSandyBridge.td file was generated by a script.
Reviewers: zvi, chandlerc, RKSimon, m_zuckerman, craig.topper, igorb
Differential Revision: https://reviews.llvm.org/D35019#inline-304691
llvm-svn: 307529
2017-07-10 17:53:16 +08:00
|
|
|
; SANDY-NEXT: vmovaps {{.*#+}} ymm1 = [1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00] sched: [7:0.50]
|
2017-08-13 21:59:24 +08:00
|
|
|
; SANDY-NEXT: vdivps %ymm0, %ymm1, %ymm0 # sched: [29:2.00]
|
This patch completely replaces the scheduling information for the SandyBridge architecture target by modifying the file X86SchedSandyBridge.td located under the X86 Target.
The SandyBridge architects have provided us with a more accurate information about each instruction latency, number of uOPs and used ports and I used it to replace the existing estimated SNB instructions scheduling and to add missing scheduling information.
Please note that the patch extensively affects the X86 MC instr scheduling for SNB.
Also note that this patch will be followed by additional patches for the remaining target architectures HSW, IVB, BDW, SKL and SKX.
The updated and extended information about each instruction includes the following details:
•static latency of the instruction
•number of uOps from which the instruction consists of
•all ports used by the instruction's' uOPs
For example, the following code dictates that instructions, ADC64mr, ADC8mr, SBB64mr, SBB8mr have a static latency of 9 cycles. Each of these instructions is decoded into 6 micro operations which use ports 4, ports 2 or 3 and port 0 and ports 0 or 1 or 5:
def SBWriteResGroup94 : SchedWriteRes<[SBPort4,SBPort23,SBPort0,SBPort015]> {
let Latency = 9;
let NumMicroOps = 6;
let ResourceCycles = [1,2,2,1];
}
def: InstRW<[SBWriteResGroup94], (instregex "ADC64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "ADC8mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB8mr")>;
Note that apart for the header, most of the X86SchedSandyBridge.td file was generated by a script.
Reviewers: zvi, chandlerc, RKSimon, m_zuckerman, craig.topper, igorb
Differential Revision: https://reviews.llvm.org/D35019#inline-304691
llvm-svn: 307529
2017-07-10 17:53:16 +08:00
|
|
|
; SANDY-NEXT: retq # sched: [1:1.00]
|
2017-02-06 02:26:17 +08:00
|
|
|
;
|
|
|
|
|
; HASWELL-LABEL: v8f32_no_estimate:
|
|
|
|
|
; HASWELL: # BB#0:
|
2017-08-28 18:04:16 +08:00
|
|
|
; HASWELL-NEXT: vbroadcastss {{.*#+}} ymm1 = [1,1,1,1,1,1,1,1] sched: [1:0.50]
|
|
|
|
|
; HASWELL-NEXT: vdivps %ymm0, %ymm1, %ymm0 # sched: [21:2.00]
|
|
|
|
|
; HASWELL-NEXT: retq # sched: [2:1.00]
|
2017-02-06 02:26:17 +08:00
|
|
|
;
|
2017-02-09 22:14:06 +08:00
|
|
|
; HASWELL-NO-FMA-LABEL: v8f32_no_estimate:
|
|
|
|
|
; HASWELL-NO-FMA: # BB#0:
|
2017-07-04 13:46:11 +08:00
|
|
|
; HASWELL-NO-FMA-NEXT: vbroadcastss {{.*#+}} ymm1 = [1,1,1,1,1,1,1,1]
|
2017-02-09 22:14:06 +08:00
|
|
|
; HASWELL-NO-FMA-NEXT: vdivps %ymm0, %ymm1, %ymm0
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: retq
|
|
|
|
|
;
|
2017-09-19 14:19:27 +08:00
|
|
|
; KNL-LABEL: v8f32_no_estimate:
|
|
|
|
|
; KNL: # BB#0:
|
|
|
|
|
; KNL-NEXT: vbroadcastss {{.*#+}} ymm1 = [1,1,1,1,1,1,1,1] sched: [1:0.50]
|
|
|
|
|
; KNL-NEXT: vdivps %ymm0, %ymm1, %ymm0 # sched: [21:2.00]
|
|
|
|
|
; KNL-NEXT: retq # sched: [2:1.00]
|
|
|
|
|
;
|
|
|
|
|
; SKX-LABEL: v8f32_no_estimate:
|
|
|
|
|
; SKX: # BB#0:
|
|
|
|
|
; SKX-NEXT: vbroadcastss {{.*#+}} ymm1 = [1,1,1,1,1,1,1,1] sched: [1:0.50]
|
|
|
|
|
; SKX-NEXT: vdivps %ymm0, %ymm1, %ymm0 # sched: [11:1.00]
|
|
|
|
|
; SKX-NEXT: retq # sched: [2:1.00]
|
2014-11-12 04:51:00 +08:00
|
|
|
%div = fdiv fast <8 x float> <float 1.0, float 1.0, float 1.0, float 1.0, float 1.0, float 1.0, float 1.0, float 1.0>, %x
|
|
|
|
|
ret <8 x float> %div
|
2016-10-05 04:46:43 +08:00
|
|
|
}
|
2014-11-12 04:51:00 +08:00
|
|
|
|
2016-10-05 04:46:43 +08:00
|
|
|
define <8 x float> @v8f32_one_step(<8 x float> %x) #1 {
|
2016-11-21 23:28:21 +08:00
|
|
|
; SSE-LABEL: v8f32_one_step:
|
|
|
|
|
; SSE: # BB#0:
|
|
|
|
|
; SSE-NEXT: rcpps %xmm0, %xmm4
|
|
|
|
|
; SSE-NEXT: mulps %xmm4, %xmm0
|
|
|
|
|
; SSE-NEXT: movaps {{.*#+}} xmm2 = [1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00]
|
|
|
|
|
; SSE-NEXT: movaps %xmm2, %xmm3
|
|
|
|
|
; SSE-NEXT: subps %xmm0, %xmm3
|
|
|
|
|
; SSE-NEXT: mulps %xmm4, %xmm3
|
|
|
|
|
; SSE-NEXT: addps %xmm4, %xmm3
|
|
|
|
|
; SSE-NEXT: rcpps %xmm1, %xmm0
|
|
|
|
|
; SSE-NEXT: mulps %xmm0, %xmm1
|
|
|
|
|
; SSE-NEXT: subps %xmm1, %xmm2
|
|
|
|
|
; SSE-NEXT: mulps %xmm0, %xmm2
|
|
|
|
|
; SSE-NEXT: addps %xmm0, %xmm2
|
|
|
|
|
; SSE-NEXT: movaps %xmm3, %xmm0
|
|
|
|
|
; SSE-NEXT: movaps %xmm2, %xmm1
|
|
|
|
|
; SSE-NEXT: retq
|
|
|
|
|
;
|
2017-02-06 02:26:17 +08:00
|
|
|
; AVX-RECIP-LABEL: v8f32_one_step:
|
|
|
|
|
; AVX-RECIP: # BB#0:
|
|
|
|
|
; AVX-RECIP-NEXT: vrcpps %ymm0, %ymm1
|
|
|
|
|
; AVX-RECIP-NEXT: vmulps %ymm1, %ymm0, %ymm0
|
|
|
|
|
; AVX-RECIP-NEXT: vmovaps {{.*#+}} ymm2 = [1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00]
|
|
|
|
|
; AVX-RECIP-NEXT: vsubps %ymm0, %ymm2, %ymm0
|
|
|
|
|
; AVX-RECIP-NEXT: vmulps %ymm0, %ymm1, %ymm0
|
|
|
|
|
; AVX-RECIP-NEXT: vaddps %ymm0, %ymm1, %ymm0
|
|
|
|
|
; AVX-RECIP-NEXT: retq
|
|
|
|
|
;
|
2017-02-09 22:14:06 +08:00
|
|
|
; FMA-RECIP-LABEL: v8f32_one_step:
|
|
|
|
|
; FMA-RECIP: # BB#0:
|
|
|
|
|
; FMA-RECIP-NEXT: vrcpps %ymm0, %ymm1
|
|
|
|
|
; FMA-RECIP-NEXT: vfnmadd213ps {{.*}}(%rip), %ymm1, %ymm0
|
|
|
|
|
; FMA-RECIP-NEXT: vfmadd132ps %ymm1, %ymm1, %ymm0
|
|
|
|
|
; FMA-RECIP-NEXT: retq
|
|
|
|
|
;
|
2017-02-06 02:26:17 +08:00
|
|
|
; BTVER2-LABEL: v8f32_one_step:
|
|
|
|
|
; BTVER2: # BB#0:
|
2017-04-14 15:44:23 +08:00
|
|
|
; BTVER2-NEXT: vmovaps {{.*#+}} ymm2 = [1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00] sched: [5:1.00]
|
2017-07-11 00:36:03 +08:00
|
|
|
; BTVER2-NEXT: vrcpps %ymm0, %ymm1 # sched: [2:2.00]
|
|
|
|
|
; BTVER2-NEXT: vmulps %ymm1, %ymm0, %ymm0 # sched: [2:2.00]
|
|
|
|
|
; BTVER2-NEXT: vsubps %ymm0, %ymm2, %ymm0 # sched: [3:2.00]
|
|
|
|
|
; BTVER2-NEXT: vmulps %ymm0, %ymm1, %ymm0 # sched: [2:2.00]
|
|
|
|
|
; BTVER2-NEXT: vaddps %ymm0, %ymm1, %ymm0 # sched: [3:2.00]
|
2017-04-14 15:44:23 +08:00
|
|
|
; BTVER2-NEXT: retq # sched: [4:1.00]
|
2017-02-06 02:26:17 +08:00
|
|
|
;
|
|
|
|
|
; SANDY-LABEL: v8f32_one_step:
|
|
|
|
|
; SANDY: # BB#0:
|
2017-08-13 21:59:24 +08:00
|
|
|
; SANDY-NEXT: vrcpps %ymm0, %ymm1 # sched: [7:2.00]
|
2017-04-14 15:44:23 +08:00
|
|
|
; SANDY-NEXT: vmulps %ymm1, %ymm0, %ymm0 # sched: [5:1.00]
|
This patch completely replaces the scheduling information for the SandyBridge architecture target by modifying the file X86SchedSandyBridge.td located under the X86 Target.
The SandyBridge architects have provided us with a more accurate information about each instruction latency, number of uOPs and used ports and I used it to replace the existing estimated SNB instructions scheduling and to add missing scheduling information.
Please note that the patch extensively affects the X86 MC instr scheduling for SNB.
Also note that this patch will be followed by additional patches for the remaining target architectures HSW, IVB, BDW, SKL and SKX.
The updated and extended information about each instruction includes the following details:
•static latency of the instruction
•number of uOps from which the instruction consists of
•all ports used by the instruction's' uOPs
For example, the following code dictates that instructions, ADC64mr, ADC8mr, SBB64mr, SBB8mr have a static latency of 9 cycles. Each of these instructions is decoded into 6 micro operations which use ports 4, ports 2 or 3 and port 0 and ports 0 or 1 or 5:
def SBWriteResGroup94 : SchedWriteRes<[SBPort4,SBPort23,SBPort0,SBPort015]> {
let Latency = 9;
let NumMicroOps = 6;
let ResourceCycles = [1,2,2,1];
}
def: InstRW<[SBWriteResGroup94], (instregex "ADC64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "ADC8mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB8mr")>;
Note that apart for the header, most of the X86SchedSandyBridge.td file was generated by a script.
Reviewers: zvi, chandlerc, RKSimon, m_zuckerman, craig.topper, igorb
Differential Revision: https://reviews.llvm.org/D35019#inline-304691
llvm-svn: 307529
2017-07-10 17:53:16 +08:00
|
|
|
; SANDY-NEXT: vmovaps {{.*#+}} ymm2 = [1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00] sched: [7:0.50]
|
2017-04-14 15:44:23 +08:00
|
|
|
; SANDY-NEXT: vsubps %ymm0, %ymm2, %ymm0 # sched: [3:1.00]
|
|
|
|
|
; SANDY-NEXT: vmulps %ymm0, %ymm1, %ymm0 # sched: [5:1.00]
|
|
|
|
|
; SANDY-NEXT: vaddps %ymm0, %ymm1, %ymm0 # sched: [3:1.00]
|
This patch completely replaces the scheduling information for the SandyBridge architecture target by modifying the file X86SchedSandyBridge.td located under the X86 Target.
The SandyBridge architects have provided us with a more accurate information about each instruction latency, number of uOPs and used ports and I used it to replace the existing estimated SNB instructions scheduling and to add missing scheduling information.
Please note that the patch extensively affects the X86 MC instr scheduling for SNB.
Also note that this patch will be followed by additional patches for the remaining target architectures HSW, IVB, BDW, SKL and SKX.
The updated and extended information about each instruction includes the following details:
•static latency of the instruction
•number of uOps from which the instruction consists of
•all ports used by the instruction's' uOPs
For example, the following code dictates that instructions, ADC64mr, ADC8mr, SBB64mr, SBB8mr have a static latency of 9 cycles. Each of these instructions is decoded into 6 micro operations which use ports 4, ports 2 or 3 and port 0 and ports 0 or 1 or 5:
def SBWriteResGroup94 : SchedWriteRes<[SBPort4,SBPort23,SBPort0,SBPort015]> {
let Latency = 9;
let NumMicroOps = 6;
let ResourceCycles = [1,2,2,1];
}
def: InstRW<[SBWriteResGroup94], (instregex "ADC64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "ADC8mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB8mr")>;
Note that apart for the header, most of the X86SchedSandyBridge.td file was generated by a script.
Reviewers: zvi, chandlerc, RKSimon, m_zuckerman, craig.topper, igorb
Differential Revision: https://reviews.llvm.org/D35019#inline-304691
llvm-svn: 307529
2017-07-10 17:53:16 +08:00
|
|
|
; SANDY-NEXT: retq # sched: [1:1.00]
|
2017-02-06 02:26:17 +08:00
|
|
|
;
|
|
|
|
|
; HASWELL-LABEL: v8f32_one_step:
|
|
|
|
|
; HASWELL: # BB#0:
|
2017-08-28 18:04:16 +08:00
|
|
|
; HASWELL-NEXT: vrcpps %ymm0, %ymm1 # sched: [11:2.00]
|
|
|
|
|
; HASWELL-NEXT: vbroadcastss {{.*#+}} ymm2 = [1,1,1,1,1,1,1,1] sched: [1:0.50]
|
|
|
|
|
; HASWELL-NEXT: vfnmadd213ps %ymm2, %ymm1, %ymm0 # sched: [5:0.50]
|
|
|
|
|
; HASWELL-NEXT: vfmadd132ps %ymm1, %ymm1, %ymm0 # sched: [5:0.50]
|
|
|
|
|
; HASWELL-NEXT: retq # sched: [2:1.00]
|
2017-02-06 02:26:17 +08:00
|
|
|
;
|
2017-02-09 22:14:06 +08:00
|
|
|
; HASWELL-NO-FMA-LABEL: v8f32_one_step:
|
|
|
|
|
; HASWELL-NO-FMA: # BB#0:
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vrcpps %ymm0, %ymm1
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vmulps %ymm1, %ymm0, %ymm0
|
2017-07-04 13:46:11 +08:00
|
|
|
; HASWELL-NO-FMA-NEXT: vbroadcastss {{.*#+}} ymm2 = [1,1,1,1,1,1,1,1]
|
2017-02-09 22:14:06 +08:00
|
|
|
; HASWELL-NO-FMA-NEXT: vsubps %ymm0, %ymm2, %ymm0
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vmulps %ymm0, %ymm1, %ymm0
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vaddps %ymm0, %ymm1, %ymm0
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: retq
|
|
|
|
|
;
|
2017-02-06 02:26:17 +08:00
|
|
|
; KNL-LABEL: v8f32_one_step:
|
|
|
|
|
; KNL: # BB#0:
|
2017-08-28 18:04:16 +08:00
|
|
|
; KNL-NEXT: vrcpps %ymm0, %ymm1 # sched: [11:2.00]
|
|
|
|
|
; KNL-NEXT: vbroadcastss {{.*#+}} ymm2 = [1,1,1,1,1,1,1,1] sched: [1:0.50]
|
|
|
|
|
; KNL-NEXT: vfnmadd213ps %ymm2, %ymm1, %ymm0 # sched: [5:0.50]
|
|
|
|
|
; KNL-NEXT: vfmadd132ps %ymm1, %ymm1, %ymm0 # sched: [5:0.50]
|
|
|
|
|
; KNL-NEXT: retq # sched: [2:1.00]
|
2017-02-06 02:26:17 +08:00
|
|
|
;
|
|
|
|
|
; SKX-LABEL: v8f32_one_step:
|
|
|
|
|
; SKX: # BB#0:
|
|
|
|
|
; SKX-NEXT: vrcp14ps %ymm0, %ymm1
|
|
|
|
|
; SKX-NEXT: vfnmadd213ps {{.*}}(%rip){1to8}, %ymm1, %ymm0
|
2017-09-19 14:19:27 +08:00
|
|
|
; SKX-NEXT: vfmadd132ps %ymm1, %ymm1, %ymm0 # sched: [4:0.50]
|
2017-08-28 18:04:16 +08:00
|
|
|
; SKX-NEXT: retq # sched: [2:1.00]
|
2016-10-05 04:46:43 +08:00
|
|
|
%div = fdiv fast <8 x float> <float 1.0, float 1.0, float 1.0, float 1.0, float 1.0, float 1.0, float 1.0, float 1.0>, %x
|
|
|
|
|
ret <8 x float> %div
|
|
|
|
|
}
|
2014-11-13 05:39:01 +08:00
|
|
|
|
2016-10-05 04:46:43 +08:00
|
|
|
define <8 x float> @v8f32_two_step(<8 x float> %x) #2 {
|
2016-11-21 23:28:21 +08:00
|
|
|
; SSE-LABEL: v8f32_two_step:
|
|
|
|
|
; SSE: # BB#0:
|
|
|
|
|
; SSE-NEXT: movaps %xmm1, %xmm2
|
|
|
|
|
; SSE-NEXT: rcpps %xmm0, %xmm3
|
|
|
|
|
; SSE-NEXT: movaps %xmm0, %xmm4
|
|
|
|
|
; SSE-NEXT: mulps %xmm3, %xmm4
|
|
|
|
|
; SSE-NEXT: movaps {{.*#+}} xmm1 = [1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00]
|
|
|
|
|
; SSE-NEXT: movaps %xmm1, %xmm5
|
|
|
|
|
; SSE-NEXT: subps %xmm4, %xmm5
|
|
|
|
|
; SSE-NEXT: mulps %xmm3, %xmm5
|
|
|
|
|
; SSE-NEXT: addps %xmm3, %xmm5
|
|
|
|
|
; SSE-NEXT: mulps %xmm5, %xmm0
|
|
|
|
|
; SSE-NEXT: movaps %xmm1, %xmm3
|
|
|
|
|
; SSE-NEXT: subps %xmm0, %xmm3
|
|
|
|
|
; SSE-NEXT: mulps %xmm5, %xmm3
|
|
|
|
|
; SSE-NEXT: addps %xmm5, %xmm3
|
|
|
|
|
; SSE-NEXT: rcpps %xmm2, %xmm0
|
|
|
|
|
; SSE-NEXT: movaps %xmm2, %xmm4
|
|
|
|
|
; SSE-NEXT: mulps %xmm0, %xmm4
|
|
|
|
|
; SSE-NEXT: movaps %xmm1, %xmm5
|
|
|
|
|
; SSE-NEXT: subps %xmm4, %xmm5
|
|
|
|
|
; SSE-NEXT: mulps %xmm0, %xmm5
|
|
|
|
|
; SSE-NEXT: addps %xmm0, %xmm5
|
|
|
|
|
; SSE-NEXT: mulps %xmm5, %xmm2
|
|
|
|
|
; SSE-NEXT: subps %xmm2, %xmm1
|
|
|
|
|
; SSE-NEXT: mulps %xmm5, %xmm1
|
|
|
|
|
; SSE-NEXT: addps %xmm5, %xmm1
|
|
|
|
|
; SSE-NEXT: movaps %xmm3, %xmm0
|
|
|
|
|
; SSE-NEXT: retq
|
|
|
|
|
;
|
2017-02-06 02:26:17 +08:00
|
|
|
; AVX-RECIP-LABEL: v8f32_two_step:
|
|
|
|
|
; AVX-RECIP: # BB#0:
|
|
|
|
|
; AVX-RECIP-NEXT: vrcpps %ymm0, %ymm1
|
|
|
|
|
; AVX-RECIP-NEXT: vmulps %ymm1, %ymm0, %ymm2
|
|
|
|
|
; AVX-RECIP-NEXT: vmovaps {{.*#+}} ymm3 = [1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00]
|
|
|
|
|
; AVX-RECIP-NEXT: vsubps %ymm2, %ymm3, %ymm2
|
|
|
|
|
; AVX-RECIP-NEXT: vmulps %ymm2, %ymm1, %ymm2
|
|
|
|
|
; AVX-RECIP-NEXT: vaddps %ymm2, %ymm1, %ymm1
|
|
|
|
|
; AVX-RECIP-NEXT: vmulps %ymm1, %ymm0, %ymm0
|
|
|
|
|
; AVX-RECIP-NEXT: vsubps %ymm0, %ymm3, %ymm0
|
|
|
|
|
; AVX-RECIP-NEXT: vmulps %ymm0, %ymm1, %ymm0
|
|
|
|
|
; AVX-RECIP-NEXT: vaddps %ymm0, %ymm1, %ymm0
|
|
|
|
|
; AVX-RECIP-NEXT: retq
|
|
|
|
|
;
|
2017-02-09 22:14:06 +08:00
|
|
|
; FMA-RECIP-LABEL: v8f32_two_step:
|
|
|
|
|
; FMA-RECIP: # BB#0:
|
|
|
|
|
; FMA-RECIP-NEXT: vrcpps %ymm0, %ymm1
|
|
|
|
|
; FMA-RECIP-NEXT: vmovaps {{.*#+}} ymm2 = [1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00]
|
|
|
|
|
; FMA-RECIP-NEXT: vmovaps %ymm1, %ymm3
|
|
|
|
|
; FMA-RECIP-NEXT: vfnmadd213ps %ymm2, %ymm0, %ymm3
|
|
|
|
|
; FMA-RECIP-NEXT: vfmadd132ps %ymm1, %ymm1, %ymm3
|
|
|
|
|
; FMA-RECIP-NEXT: vfnmadd213ps %ymm2, %ymm3, %ymm0
|
|
|
|
|
; FMA-RECIP-NEXT: vfmadd132ps %ymm3, %ymm3, %ymm0
|
|
|
|
|
; FMA-RECIP-NEXT: retq
|
|
|
|
|
;
|
2017-02-06 02:26:17 +08:00
|
|
|
; BTVER2-LABEL: v8f32_two_step:
|
|
|
|
|
; BTVER2: # BB#0:
|
2017-04-14 15:44:23 +08:00
|
|
|
; BTVER2-NEXT: vmovaps {{.*#+}} ymm3 = [1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00] sched: [5:1.00]
|
2017-07-11 00:36:03 +08:00
|
|
|
; BTVER2-NEXT: vrcpps %ymm0, %ymm1 # sched: [2:2.00]
|
|
|
|
|
; BTVER2-NEXT: vmulps %ymm1, %ymm0, %ymm2 # sched: [2:2.00]
|
|
|
|
|
; BTVER2-NEXT: vsubps %ymm2, %ymm3, %ymm2 # sched: [3:2.00]
|
|
|
|
|
; BTVER2-NEXT: vmulps %ymm2, %ymm1, %ymm2 # sched: [2:2.00]
|
|
|
|
|
; BTVER2-NEXT: vaddps %ymm2, %ymm1, %ymm1 # sched: [3:2.00]
|
|
|
|
|
; BTVER2-NEXT: vmulps %ymm1, %ymm0, %ymm0 # sched: [2:2.00]
|
|
|
|
|
; BTVER2-NEXT: vsubps %ymm0, %ymm3, %ymm0 # sched: [3:2.00]
|
|
|
|
|
; BTVER2-NEXT: vmulps %ymm0, %ymm1, %ymm0 # sched: [2:2.00]
|
|
|
|
|
; BTVER2-NEXT: vaddps %ymm0, %ymm1, %ymm0 # sched: [3:2.00]
|
2017-04-14 15:44:23 +08:00
|
|
|
; BTVER2-NEXT: retq # sched: [4:1.00]
|
2017-02-06 02:26:17 +08:00
|
|
|
;
|
|
|
|
|
; SANDY-LABEL: v8f32_two_step:
|
|
|
|
|
; SANDY: # BB#0:
|
2017-08-13 21:59:24 +08:00
|
|
|
; SANDY-NEXT: vrcpps %ymm0, %ymm1 # sched: [7:2.00]
|
2017-04-14 15:44:23 +08:00
|
|
|
; SANDY-NEXT: vmulps %ymm1, %ymm0, %ymm2 # sched: [5:1.00]
|
This patch completely replaces the scheduling information for the SandyBridge architecture target by modifying the file X86SchedSandyBridge.td located under the X86 Target.
The SandyBridge architects have provided us with a more accurate information about each instruction latency, number of uOPs and used ports and I used it to replace the existing estimated SNB instructions scheduling and to add missing scheduling information.
Please note that the patch extensively affects the X86 MC instr scheduling for SNB.
Also note that this patch will be followed by additional patches for the remaining target architectures HSW, IVB, BDW, SKL and SKX.
The updated and extended information about each instruction includes the following details:
•static latency of the instruction
•number of uOps from which the instruction consists of
•all ports used by the instruction's' uOPs
For example, the following code dictates that instructions, ADC64mr, ADC8mr, SBB64mr, SBB8mr have a static latency of 9 cycles. Each of these instructions is decoded into 6 micro operations which use ports 4, ports 2 or 3 and port 0 and ports 0 or 1 or 5:
def SBWriteResGroup94 : SchedWriteRes<[SBPort4,SBPort23,SBPort0,SBPort015]> {
let Latency = 9;
let NumMicroOps = 6;
let ResourceCycles = [1,2,2,1];
}
def: InstRW<[SBWriteResGroup94], (instregex "ADC64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "ADC8mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB8mr")>;
Note that apart for the header, most of the X86SchedSandyBridge.td file was generated by a script.
Reviewers: zvi, chandlerc, RKSimon, m_zuckerman, craig.topper, igorb
Differential Revision: https://reviews.llvm.org/D35019#inline-304691
llvm-svn: 307529
2017-07-10 17:53:16 +08:00
|
|
|
; SANDY-NEXT: vmovaps {{.*#+}} ymm3 = [1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00,1.000000e+00] sched: [7:0.50]
|
2017-04-14 15:44:23 +08:00
|
|
|
; SANDY-NEXT: vsubps %ymm2, %ymm3, %ymm2 # sched: [3:1.00]
|
|
|
|
|
; SANDY-NEXT: vmulps %ymm2, %ymm1, %ymm2 # sched: [5:1.00]
|
|
|
|
|
; SANDY-NEXT: vaddps %ymm2, %ymm1, %ymm1 # sched: [3:1.00]
|
|
|
|
|
; SANDY-NEXT: vmulps %ymm1, %ymm0, %ymm0 # sched: [5:1.00]
|
|
|
|
|
; SANDY-NEXT: vsubps %ymm0, %ymm3, %ymm0 # sched: [3:1.00]
|
|
|
|
|
; SANDY-NEXT: vmulps %ymm0, %ymm1, %ymm0 # sched: [5:1.00]
|
|
|
|
|
; SANDY-NEXT: vaddps %ymm0, %ymm1, %ymm0 # sched: [3:1.00]
|
This patch completely replaces the scheduling information for the SandyBridge architecture target by modifying the file X86SchedSandyBridge.td located under the X86 Target.
The SandyBridge architects have provided us with a more accurate information about each instruction latency, number of uOPs and used ports and I used it to replace the existing estimated SNB instructions scheduling and to add missing scheduling information.
Please note that the patch extensively affects the X86 MC instr scheduling for SNB.
Also note that this patch will be followed by additional patches for the remaining target architectures HSW, IVB, BDW, SKL and SKX.
The updated and extended information about each instruction includes the following details:
•static latency of the instruction
•number of uOps from which the instruction consists of
•all ports used by the instruction's' uOPs
For example, the following code dictates that instructions, ADC64mr, ADC8mr, SBB64mr, SBB8mr have a static latency of 9 cycles. Each of these instructions is decoded into 6 micro operations which use ports 4, ports 2 or 3 and port 0 and ports 0 or 1 or 5:
def SBWriteResGroup94 : SchedWriteRes<[SBPort4,SBPort23,SBPort0,SBPort015]> {
let Latency = 9;
let NumMicroOps = 6;
let ResourceCycles = [1,2,2,1];
}
def: InstRW<[SBWriteResGroup94], (instregex "ADC64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "ADC8mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB8mr")>;
Note that apart for the header, most of the X86SchedSandyBridge.td file was generated by a script.
Reviewers: zvi, chandlerc, RKSimon, m_zuckerman, craig.topper, igorb
Differential Revision: https://reviews.llvm.org/D35019#inline-304691
llvm-svn: 307529
2017-07-10 17:53:16 +08:00
|
|
|
; SANDY-NEXT: retq # sched: [1:1.00]
|
2017-02-06 02:26:17 +08:00
|
|
|
;
|
|
|
|
|
; HASWELL-LABEL: v8f32_two_step:
|
|
|
|
|
; HASWELL: # BB#0:
|
2017-08-28 18:04:16 +08:00
|
|
|
; HASWELL-NEXT: vrcpps %ymm0, %ymm1 # sched: [11:2.00]
|
|
|
|
|
; HASWELL-NEXT: vbroadcastss {{.*#+}} ymm2 = [1,1,1,1,1,1,1,1] sched: [1:0.50]
|
2017-04-14 15:44:23 +08:00
|
|
|
; HASWELL-NEXT: vmovaps %ymm1, %ymm3 # sched: [1:1.00]
|
2017-08-28 18:04:16 +08:00
|
|
|
; HASWELL-NEXT: vfnmadd213ps %ymm2, %ymm0, %ymm3 # sched: [5:0.50]
|
|
|
|
|
; HASWELL-NEXT: vfmadd132ps %ymm1, %ymm1, %ymm3 # sched: [5:0.50]
|
|
|
|
|
; HASWELL-NEXT: vfnmadd213ps %ymm2, %ymm3, %ymm0 # sched: [5:0.50]
|
|
|
|
|
; HASWELL-NEXT: vfmadd132ps %ymm3, %ymm3, %ymm0 # sched: [5:0.50]
|
|
|
|
|
; HASWELL-NEXT: retq # sched: [2:1.00]
|
2017-02-06 02:26:17 +08:00
|
|
|
;
|
2017-02-09 22:14:06 +08:00
|
|
|
; HASWELL-NO-FMA-LABEL: v8f32_two_step:
|
|
|
|
|
; HASWELL-NO-FMA: # BB#0:
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vrcpps %ymm0, %ymm1
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vmulps %ymm1, %ymm0, %ymm2
|
2017-07-04 13:46:11 +08:00
|
|
|
; HASWELL-NO-FMA-NEXT: vbroadcastss {{.*#+}} ymm3 = [1,1,1,1,1,1,1,1]
|
2017-02-09 22:14:06 +08:00
|
|
|
; HASWELL-NO-FMA-NEXT: vsubps %ymm2, %ymm3, %ymm2
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vmulps %ymm2, %ymm1, %ymm2
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vaddps %ymm2, %ymm1, %ymm1
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vmulps %ymm1, %ymm0, %ymm0
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vsubps %ymm0, %ymm3, %ymm0
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vmulps %ymm0, %ymm1, %ymm0
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: vaddps %ymm0, %ymm1, %ymm0
|
|
|
|
|
; HASWELL-NO-FMA-NEXT: retq
|
|
|
|
|
;
|
2017-02-06 02:26:17 +08:00
|
|
|
; KNL-LABEL: v8f32_two_step:
|
|
|
|
|
; KNL: # BB#0:
|
2017-08-28 18:04:16 +08:00
|
|
|
; KNL-NEXT: vrcpps %ymm0, %ymm1 # sched: [11:2.00]
|
|
|
|
|
; KNL-NEXT: vbroadcastss {{.*#+}} ymm2 = [1,1,1,1,1,1,1,1] sched: [1:0.50]
|
2017-04-14 15:44:23 +08:00
|
|
|
; KNL-NEXT: vmovaps %ymm1, %ymm3 # sched: [1:1.00]
|
2017-08-28 18:04:16 +08:00
|
|
|
; KNL-NEXT: vfnmadd213ps %ymm2, %ymm0, %ymm3 # sched: [5:0.50]
|
|
|
|
|
; KNL-NEXT: vfmadd132ps %ymm1, %ymm1, %ymm3 # sched: [5:0.50]
|
|
|
|
|
; KNL-NEXT: vfnmadd213ps %ymm2, %ymm3, %ymm0 # sched: [5:0.50]
|
|
|
|
|
; KNL-NEXT: vfmadd132ps %ymm3, %ymm3, %ymm0 # sched: [5:0.50]
|
|
|
|
|
; KNL-NEXT: retq # sched: [2:1.00]
|
2017-02-06 02:26:17 +08:00
|
|
|
;
|
|
|
|
|
; SKX-LABEL: v8f32_two_step:
|
|
|
|
|
; SKX: # BB#0:
|
|
|
|
|
; SKX-NEXT: vrcp14ps %ymm0, %ymm1
|
2017-08-28 18:04:16 +08:00
|
|
|
; SKX-NEXT: vbroadcastss {{.*#+}} ymm2 = [1,1,1,1,1,1,1,1] sched: [1:0.50]
|
2017-04-14 15:44:23 +08:00
|
|
|
; SKX-NEXT: vmovaps %ymm1, %ymm3 # sched: [1:1.00]
|
2017-09-19 14:19:27 +08:00
|
|
|
; SKX-NEXT: vfnmadd213ps %ymm2, %ymm0, %ymm3 # sched: [4:0.50]
|
|
|
|
|
; SKX-NEXT: vfmadd132ps %ymm1, %ymm1, %ymm3 # sched: [4:0.50]
|
|
|
|
|
; SKX-NEXT: vfnmadd213ps %ymm2, %ymm3, %ymm0 # sched: [4:0.50]
|
|
|
|
|
; SKX-NEXT: vfmadd132ps %ymm3, %ymm3, %ymm0 # sched: [4:0.50]
|
2017-08-28 18:04:16 +08:00
|
|
|
; SKX-NEXT: retq # sched: [2:1.00]
|
2016-10-05 04:46:43 +08:00
|
|
|
%div = fdiv fast <8 x float> <float 1.0, float 1.0, float 1.0, float 1.0, float 1.0, float 1.0, float 1.0, float 1.0>, %x
|
|
|
|
|
ret <8 x float> %div
|
2014-11-12 04:51:00 +08:00
|
|
|
}
|
|
|
|
|
|
2016-10-05 04:46:43 +08:00
|
|
|
attributes #0 = { "unsafe-fp-math"="true" "reciprocal-estimates"="!divf,!vec-divf" }
|
|
|
|
|
attributes #1 = { "unsafe-fp-math"="true" "reciprocal-estimates"="divf,vec-divf" }
|
|
|
|
|
attributes #2 = { "unsafe-fp-math"="true" "reciprocal-estimates"="divf:2,vec-divf:2" }
|
|
|
|
|
|