mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-10-22 20:43:44 +02:00
e3955cf340
Assuming the default FP env, we should not treat fdiv and frem any differently in terms of trapping behavior than any other FP op. Ie, FP ops do not trap with the default FP env. This matches how we treat these ops in IR with isSafeToSpeculativelyExecute(). There's a similar bug in Constant::canTrap(). This bug manifests in PR29114: https://llvm.org/bugs/show_bug.cgi?id=29114 ...as a sequence of scalar divisions instead of a vector division on x86 for a <3 x float> type. Differential Revision: https://reviews.llvm.org/D23974 llvm-svn: 279970
33 lines
1.1 KiB
LLVM
33 lines
1.1 KiB
LLVM
; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
|
|
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=sse | FileCheck %s
|
|
|
|
define <3 x float> @fadd(<3 x float> %v, float %d) {
|
|
; CHECK-LABEL: fadd:
|
|
; CHECK: # BB#0:
|
|
; CHECK-NEXT: shufps {{.*#+}} xmm1 = xmm1[0,0,0,3]
|
|
; CHECK-NEXT: addps %xmm1, %xmm0
|
|
; CHECK-NEXT: retq
|
|
;
|
|
%ins = insertelement <3 x float> undef, float %d, i32 0
|
|
%splat = shufflevector <3 x float> %ins, <3 x float> undef, <3 x i32> zeroinitializer
|
|
%add = fadd <3 x float> %splat, %v
|
|
ret <3 x float> %add
|
|
}
|
|
|
|
; PR29114: https://llvm.org/bugs/show_bug.cgi?id=29114
|
|
|
|
define <3 x float> @fdiv(<3 x float> %v, float %d) {
|
|
; CHECK-LABEL: fdiv:
|
|
; CHECK: # BB#0:
|
|
; CHECK-NEXT: shufps {{.*#+}} xmm1 = xmm1[0,0,0,3]
|
|
; CHECK-NEXT: divps %xmm0, %xmm1
|
|
; CHECK-NEXT: movaps %xmm1, %xmm0
|
|
; CHECK-NEXT: retq
|
|
;
|
|
%ins = insertelement <3 x float> undef, float %d, i32 0
|
|
%splat = shufflevector <3 x float> %ins, <3 x float> undef, <3 x i32> zeroinitializer
|
|
%div = fdiv <3 x float> %splat, %v
|
|
ret <3 x float> %div
|
|
}
|
|
|