[PATCH] D11471: Scalar to vector conversions using direct moves

Nemanja Ivanovic nemanja.i.ibm at gmail.com
Wed Jul 29 12:54:21 PDT 2015


nemanjai added inline comments.

================
Comment at: lib/Target/PowerPC/PPCInstrVSX.td:1240
@@ +1239,3 @@
+                    (INSERT_SUBREG (i64 (IMPLICIT_DEF)), $A, sub_32), 32, 31));
+  dag DBLWORD_0 = (MTVSRD $A);
+
----------------
wschmidt wrote:
> BE_DWORD_0?  This isn't an LE pattern, so it needs a BE designator, correct?  Even though it's used in an LE pattern, it is LE doubleword 1 there, so naming it BE_DWORD_0 is more expressive.
Fair enough, the value needs to be shifted/swapped for LE, so I'll rename it to BE_DWORD_0. And the subsequent swap will put it in LE doubleword 0.

================
Comment at: lib/Target/PowerPC/PPCInstrVSX.td:1247
@@ +1246,3 @@
+  dag LE_DBL = (XXPERMDI LE_CPD, LE_CPD, 2);
+}
+
----------------
wschmidt wrote:
> I find LE_BHW and LE_DBL to be pretty incomprehensible names.  For consistency and understanding, I would name them LE_WORD_0 and LE_DWORD_0.  Also, LE_CPW is arguably LE_WORD_1 and LE_CPD is LE_DWORD_1.  This gives the more understandable:
> 
>   dag LE_DWORD_1 = (v2i64 (COPY_TO_REGCLASS BE_DWORD_0, VSRC));
> 
> reinforcing that LE doubleword 1 is the same as BE doubleword 0.
> 
> I don't much care what you call LE_MVW so long as it is readable and implies moving an integer to a vector register.  Longer meaningful names beat brief incomprehensible ones.  Of course that's still better than long incomprehensible ones. ;)
OK, I will rename them as you suggest:
LE_BHW -> LE_WORD_0
LE_CPW -> LE_WORD_1
LE_DBL -> LE_DWORD_0
LE_CPD -> LE_DWORD_1

================
Comment at: test/CodeGen/PowerPC/p8-scalar_vector_conversions.ll:74
@@ +73,3 @@
+; CHECK-LE: xscvdpspn [[REG1:[0-9]+]], 1
+; CHECK-LE: xxsldwi {{[0-9]+}}, [[REG1]], [[REG1]], 1
+}
----------------
wschmidt wrote:
> I was confused by this at first, but now I get it.  In all of these tests, the code generation that you are checking for is just for the %splat.splatinsert calculation, right?  This is the part that translates into a scalar_to_vector node.  I assume that the generated code follows this up with code to splat element 0 to the entire result register, correct?
Yes, the subsequent instruction will be a splat (VSX if we have one, VMX otherwise). I can add those to the check patterns but, I can't verify the correct register (because of the "off-by-32 relationship" between the VSX and VMX registers). I was actually hoping to use the FileCheck capability of checking line numbers (ranges), but that actually looks for the word line I think. So I can add the CHECK: vsplat[bhw] and just confirm the right element in the splat instruction if you'd like.


Repository:
  rL LLVM

http://reviews.llvm.org/D11471







More information about the llvm-commits mailing list