[PATCH] D27998: [AArch64] Consider all vector types for FeatureSlowMisaligned128Store

[Evandro Menezes via Phabricator via llvm-commits]

evandro added a comment.

In https://reviews.llvm.org/D27998#637583, @mssimpso wrote:

> ... Also, please add a test case for the <4 x i64> store I mentioned previously, so we know we have the right cost.


Will do.



================
Comment at: llvm/lib/Target/AArch64/AArch64TargetTransformInfo.cpp:471
   if (ST->isMisaligned128StoreSlow() && Opcode == Instruction::Store &&
-      Src->isVectorTy() && Alignment != 16 &&
-      Src->getVectorElementType()->isIntegerTy(64)) {
-    // Unaligned stores are extremely inefficient. We don't split
-    // unaligned v2i64 stores because the negative impact that has shown in
-    // practice on inlined memcpy code.
-    // We make v2i64 stores expensive so that we will only vectorize if there
+      Src->getPrimitiveSizeInBits() == 128 && Alignment < 16) {
+    // Unaligned stores are extremely inefficient. We don't split all
----------------
mssimpso wrote:
> rengolin wrote:
> > mssimpso wrote:
> > > Would it make sense to check the legalized type here? Something like LT.second.is128BitVector()?
> > I'm not sure the type would make any difference on the store. All that matters is that this is a 128-bit store and the required alignment is larger than that. The previous conditional was weird, I think.
> I guess I was thinking about the case where Src is something like a <4 x i64>. I believe getPrimativeSizeInBits would be 256. But this should get legalized into two 128 bit stores. So isn't the size of the legalized type what matters?
I believe that at this point the type is already legalized, but I'll double check it.


Repository:
  rL LLVM

https://reviews.llvm.org/D27998