summaryrefslogtreecommitdiffstats
path: root/llvm/test/CodeGen/Mips/cconv
diff options
context:
space:
mode:
authorCraig Topper <craig.topper@intel.com>2018-08-24 17:48:25 +0000
committerCraig Topper <craig.topper@intel.com>2018-08-24 17:48:25 +0000
commitd8e91c3e8d8e7a83799337757d6e8af3a4189b5b (patch)
treead4fd85880d002e34ab7ffc5e5c2d27541037d64 /llvm/test/CodeGen/Mips/cconv
parent7cb44f2470dc61d267096fc2354d6862db69b075 (diff)
downloadbcm5719-llvm-d8e91c3e8d8e7a83799337757d6e8af3a4189b5b.tar.gz
bcm5719-llvm-d8e91c3e8d8e7a83799337757d6e8af3a4189b5b.zip
[DAGCombiner][Mips] Don't combine bitcast+store after LegalOperations when the store is volatile, if the resulting store isn't Legal
Previously we allowed the store to be Custom. But without knowing for sure that the Custom handling won't split the store, we shouldn't convert a volatile store. We also probably shouldn't be creating a store the requires custom handling after LegalizeOps. This could lead to an infinite loop if the custom handling was to insert a bitcast. Though I guess isStoreBitCastBeneficial could be used to block such a loop. The test changes here are due to the volatile part of this. The stores in the test are all volatile and i32 stores are marked custom, So we are no longer converting them This is related to D50491 where I was trying to allow some bitcasting of volatile loads Differential Revision: https://reviews.llvm.org/D50578 llvm-svn: 340626
Diffstat (limited to 'llvm/test/CodeGen/Mips/cconv')
-rw-r--r--llvm/test/CodeGen/Mips/cconv/arguments-hard-float-varargs.ll3
-rw-r--r--llvm/test/CodeGen/Mips/cconv/arguments-hard-float.ll9
2 files changed, 8 insertions, 4 deletions
diff --git a/llvm/test/CodeGen/Mips/cconv/arguments-hard-float-varargs.ll b/llvm/test/CodeGen/Mips/cconv/arguments-hard-float-varargs.ll
index 100e8b02162..6b0af667ee4 100644
--- a/llvm/test/CodeGen/Mips/cconv/arguments-hard-float-varargs.ll
+++ b/llvm/test/CodeGen/Mips/cconv/arguments-hard-float-varargs.ll
@@ -111,7 +111,8 @@ entry:
; The first four arguments are the same in O32/N32/N64.
; The non-variable portion should be unaffected.
-; O32-DAG: sw $4, 4([[R2]])
+; O32-DAG: mtc1 $4, $f0
+; O32-DAG: swc1 $f0, 4([[R2]])
; NEW-DAG: swc1 $f12, 4([[R2]])
; The varargs portion is dumped to stack
diff --git a/llvm/test/CodeGen/Mips/cconv/arguments-hard-float.ll b/llvm/test/CodeGen/Mips/cconv/arguments-hard-float.ll
index 24bb95c7c68..e98a11a8064 100644
--- a/llvm/test/CodeGen/Mips/cconv/arguments-hard-float.ll
+++ b/llvm/test/CodeGen/Mips/cconv/arguments-hard-float.ll
@@ -125,9 +125,11 @@ entry:
; I've yet to find a reference in the documentation about this but GCC uses up
; the remaining two argument slots in the GPR's first. We'll do the same for
; compatibility.
-; O32-DAG: sw $6, 12([[R1]])
+; O32-DAG: mtc1 $6, $f0
+; O32-DAG: swc1 $f0, 12([[R1]])
; NEW-DAG: swc1 $f14, 12([[R1]])
-; O32-DAG: sw $7, 16([[R1]])
+; O32-DAG: mtc1 $7, $f0
+; O32-DAG: swc1 $f0, 16([[R1]])
; NEW-DAG: swc1 $f15, 16([[R1]])
; O32 is definitely out of registers now and switches to the stack.
@@ -207,5 +209,6 @@ entry:
; MD00305 and GCC disagree on this one. MD00305 says that floats are treated
; as 8-byte aligned and occupy two slots on O32. GCC is treating them as 4-byte
; aligned and occupying one slot. We'll use GCC's definition.
-; O32-DAG: sw $5, 4([[R2]])
+; O32-DAG: mtc1 $5, $f0
+; O32-DAG: swc1 $f0, 4([[R2]])
; NEW-DAG: swc1 $f13, 4([[R2]])
OpenPOWER on IntegriCloud