[PATCH 2/2] R600/SI: Report unaligned memory accesses as legal for > 32-bit types

Tom Stellard tom at stellard.net
Tue Jun 18 09:54:17 PDT 2013


From: Tom Stellard <thomas.stellard at amd.com>

In reality, some unaligned memory accesses are legal for 32-bit types and
smaller too, but it all depends on the address space.  Allowing
unaligned loads/stores for > 32-bit types is mainly to prevent the
legalizer from splitting one load into multiple loads of smaller types.

https://bugs.freedesktop.org/show_bug.cgi?id=65873
---
 lib/Target/R600/SIISelLowering.cpp | 12 ++++++++++++
 lib/Target/R600/SIISelLowering.h   |  1 +
 test/CodeGen/R600/store.ll         | 32 ++++++++++++++++++++++++++++++++
 3 files changed, 45 insertions(+)

diff --git a/lib/Target/R600/SIISelLowering.cpp b/lib/Target/R600/SIISelLowering.cpp
index d74f401..9d4cfef 100644
--- a/lib/Target/R600/SIISelLowering.cpp
+++ b/lib/Target/R600/SIISelLowering.cpp
@@ -82,6 +82,18 @@ SITargetLowering::SITargetLowering(TargetMachine &TM) :
   setSchedulingPreference(Sched::RegPressure);
 }
 
+//===----------------------------------------------------------------------===//
+// TargetLowering queries
+//===----------------------------------------------------------------------===//
+
+bool SITargetLowering::allowsUnalignedMemoryAccesses(EVT  VT,
+                                                     bool *IsFast) const {
+  // XXX: This depends on the address space and also we may want to revist
+  // the alignment values we specify in the DataLayout.
+  return VT.bitsGT(MVT::i32);
+}
+
+
 SDValue SITargetLowering::LowerParameter(SelectionDAG &DAG, EVT VT,
                                          SDLoc DL, SDValue Chain,
                                          unsigned Offset) const {
diff --git a/lib/Target/R600/SIISelLowering.h b/lib/Target/R600/SIISelLowering.h
index 78ae6a1..0a856d5 100644
--- a/lib/Target/R600/SIISelLowering.h
+++ b/lib/Target/R600/SIISelLowering.h
@@ -40,6 +40,7 @@ class SITargetLowering : public AMDGPUTargetLowering {
 
 public:
   SITargetLowering(TargetMachine &tm);
+  bool allowsUnalignedMemoryAccesses(EVT  VT, bool *IsFast) const;
 
   SDValue LowerFormalArguments(SDValue Chain, CallingConv::ID CallConv,
                                bool isVarArg,
diff --git a/test/CodeGen/R600/store.ll b/test/CodeGen/R600/store.ll
index e87229a..f8c6f84 100644
--- a/test/CodeGen/R600/store.ll
+++ b/test/CodeGen/R600/store.ll
@@ -14,3 +14,35 @@ define void @store_f32(float addrspace(1)* %out, float %in) {
   store float %in, float addrspace(1)* %out
   ret void
 }
+
+; The stores in this function are combined by the optimizer to create a
+; 64-bit store with 32-bit alignment.  This is legal for SI and the legalizer
+; should not try to split the 64-bit store back into 2 32-bit stores.
+;
+; Evergreen / Northern Islands don't support 64-bit stores yet, so there should
+; be two 32-bit stores.
+
+; EG-CHECK: @vecload2
+; EG-CHECK: RAT_WRITE_CACHELESS_32_eg
+; EG-CHECK: RAT_WRITE_CACHELESS_32_eg
+; CM-CHECK: @vecload2
+; CM-CHECK: EXPORT_RAT_INST_STORE_DWORD
+; CM-CHECK: EXPORT_RAT_INST_STORE_DWORD
+; SI-CHECK: @vecload2
+; SI-CHECK: BUFFER_STORE_DWORDX2
+define void @vecload2(i32 addrspace(1)* nocapture %out, i32 addrspace(2)* nocapture %mem) #0 {
+entry:
+  %0 = load i32 addrspace(2)* %mem, align 4, !tbaa !5
+  %arrayidx1.i = getelementptr inbounds i32 addrspace(2)* %mem, i64 1
+  %1 = load i32 addrspace(2)* %arrayidx1.i, align 4, !tbaa !5
+  store i32 %0, i32 addrspace(1)* %out, align 4, !tbaa !5
+  %arrayidx1 = getelementptr inbounds i32 addrspace(1)* %out, i64 1
+  store i32 %1, i32 addrspace(1)* %arrayidx1, align 4, !tbaa !5
+  ret void
+}
+
+attributes #0 = { nounwind "less-precise-fpmad"="false" "no-frame-pointer-elim"="false" "no-frame-pointer-elim-non-leaf"="false" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "unsafe-fp-math"="false" "use-soft-float"="false" }
+
+!5 = metadata !{metadata !"int", metadata !6}
+!6 = metadata !{metadata !"omnipotent char", metadata !7}
+!7 = metadata !{metadata !"Simple C/C++ TBAA"}
-- 
1.7.11.4




More information about the llvm-commits mailing list