[PATCH] Fix R0 use in PowerPC VSX store for FastIsel

Samuel Antao sfantao at us.ibm.com
Mon Mar 16 10:41:51 PDT 2015


Hi hfinkel, wschmidt,

Hi all,

I observed that for some constructors, e.g:

struct specific_fpval {
  double Val;
  specific_fpval(double V) : Val(V) {}
};

the VSX store generated to store V into Val is not specifying any offset register causing %noreg to be generated and R0 to be emitted later on. The semantics of the VSX store (e.g. stdsdx) requires R0 to be used as base if we want zero to be used in the computation of the effective address instead of the content of R0. This patch checks if no index register was generated and forces R0 to be used as base address.

This was causing clang auto-compilation to fail in Debug mode. I understand that VSX support is still work under progress, but I decided to contribute this patch in the event this is something no one else was aware. I included a regression in a separate file.

Thanks!
Samuel

http://reviews.llvm.org/D8358

Files:
  lib/Target/PowerPC/PPCFastISel.cpp
  test/CodeGen/PowerPC/fast-isel-load-store-vsx.ll

Index: lib/Target/PowerPC/PPCFastISel.cpp
===================================================================
--- lib/Target/PowerPC/PPCFastISel.cpp
+++ lib/Target/PowerPC/PPCFastISel.cpp
@@ -675,8 +675,18 @@
       case PPC::STFS: Opc = PPC::STFSX; break;
       case PPC::STFD: Opc = IsVSFRC ? PPC::STXSDX : PPC::STFDX; break;
     }
-    BuildMI(*FuncInfo.MBB, FuncInfo.InsertPt, DbgLoc, TII.get(Opc))
-      .addReg(SrcReg).addReg(Addr.Base.Reg).addReg(IndexReg);
+
+    auto MIB = BuildMI(*FuncInfo.MBB, FuncInfo.InsertPt, DbgLoc, TII.get(Opc))
+        .addReg(SrcReg);
+
+    // If we have an index register defined we use it in the store inst,
+    // otherwise we use X0 as base as it makes the vector instructions to
+    // use zero in the computation of the effective address regardless the
+    // content of the register.
+    if (IndexReg)
+      MIB.addReg(Addr.Base.Reg).addReg(IndexReg);
+    else
+      MIB.addReg(PPC::ZERO8).addReg(Addr.Base.Reg);
   }
 
   return true;
Index: test/CodeGen/PowerPC/fast-isel-load-store-vsx.ll
===================================================================
--- /dev/null
+++ test/CodeGen/PowerPC/fast-isel-load-store-vsx.ll
@@ -0,0 +1,33 @@
+;; There are some known limitations in the VSX support during FastIsel 
+;; (see fast-isel-load-store.ll header). Nevertheless, we are adding some 
+;; regressions here for bugs we fix in the meantime
+; RUN: llc < %s -O0 -fast-isel -mattr=+vsx -mtriple=powerpc64-unknown-linux-gnu -mcpu=pwr7 | FileCheck %s --check-prefix=ELF64VSX
+
+;; The semantics of VSX stores for when R0 is used is different depending on
+;; whether it is used as base or offset. If used as base, the effective
+;; address computation will use zero regardless the content of R0. If used as
+;; offset, the content will be used in the effective address. We observed that
+;; for some constructors, the initialization values were being stored without
+;; any offset register being specified which was causing R0 to be used as offset
+;; in regions where it contained the value in the link register. This regression
+;; verifies that R0 is used as base in these situations.
+
+%SomeStruct = type { double }
+
+; ELF64VSX-LABEL: SomeStructCtor
+define linkonce_odr void @SomeStructCtor(%SomeStruct* %this, double %V) unnamed_addr align 2 {
+entry:
+  %this.addr = alloca %SomeStruct*, align 8
+  %V.addr = alloca double, align 8
+  store %SomeStruct* %this, %SomeStruct** %this.addr, align 8
+; ELF64VSX: stxsdx {{[0-9][0-9]?}}, 0, {{[1-9][0-9]?}}
+  store double %V, double* %V.addr, align 8
+  %this1 = load %SomeStruct*, %SomeStruct** %this.addr
+  %Val = getelementptr inbounds %SomeStruct, %SomeStruct* %this1, i32 0, i32 0
+; ELF64VSX: stxsdx {{[0-9][0-9]?}}, 0, {{[1-9][0-9]?}}
+  %0 = load double, double* %V.addr, align 8
+  store double %0, double* %Val, align 8
+  ret void
+ } 
+
+

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D8358.22031.patch
Type: text/x-patch
Size: 2865 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150316/ce540ce1/attachment.bin>


More information about the llvm-commits mailing list