[TargetLowering] remove fdiv and frem from canOpTrap() (PR29114)

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

1 files changed, 2 insertions, 10 deletions

diff --git a/llvm/test/CodeGen/X86/vec3.ll b/llvm/test/CodeGen/X86/vec3.ll
index c7b8e54cf7e..8eaf9f4f48e 100644
--- a/llvm/test/CodeGen/X86/vec3.ll
+++ b/llvm/test/CodeGen/X86/vec3.ll
@@ -19,16 +19,8 @@ define <3 x float> @fadd(<3 x float> %v, float %d) {
 define <3 x float> @fdiv(<3 x float> %v, float %d) {
 ; CHECK-LABEL: fdiv:
 ; CHECK:       # BB#0:
-; CHECK-NEXT:    movaps %xmm1, %xmm2
-; CHECK-NEXT:    movaps %xmm0, %xmm3
-; CHECK-NEXT:    movaps %xmm1, %xmm4
-; CHECK-NEXT:    divss %xmm0, %xmm1
-; CHECK-NEXT:    shufps {{.*#+}} xmm0 = xmm0[1,1,2,3]
-; CHECK-NEXT:    divss %xmm0, %xmm2
-; CHECK-NEXT:    movhlps {{.*#+}} xmm3 = xmm3[1,1]
-; CHECK-NEXT:    divss %xmm3, %xmm4
-; CHECK-NEXT:    unpcklps {{.*#+}} xmm1 = xmm1[0],xmm4[0],xmm1[1],xmm4[1]
-; CHECK-NEXT:    unpcklps {{.*#+}} xmm1 = xmm1[0],xmm2[0],xmm1[1],xmm2[1]
+; CHECK-NEXT:    shufps {{.*#+}} xmm1 = xmm1[0,0,0,3]
+; CHECK-NEXT:    divps %xmm0, %xmm1
 ; CHECK-NEXT:    movaps %xmm1, %xmm0
 ; CHECK-NEXT:    retq
 ;