mirror of
https://github.com/RPCSX/llvm.git
synced 2025-01-26 14:25:18 +00:00
bbb2e05d37
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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279970 91177308-0d34-0410-b5e6-96231b3b80d8
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
|
|
}
|
|
|