[X86] Prevent passing vectors of __int128 as <X x i128> in llvm IR

[craig.topper]

Summary

As far as I can tell, gcc passes 256/512 bit vectors __int128 in memory. And passes a vector of 1 _int128 in an xmm register. The backend considers <X x i128> as an illegal type and will scalarize any arguments with that type. So we need to coerce the argument types in the frontend to match to avoid the illegal type.

Are there other element types to consider? Do we need to keep the old behavior on platforms where clang is the de facto compiler?

This issue was identified in PR42607. Though even with the types changed, we still seem to be doing some unnecessary stack realignment.

I'll add test cases later today or over the weekend.

[wristow]

Do we need to keep the old behavior on platforms where clang is the de facto compiler?

I know we (PlayStation) will want to keep the old behavior.

[xbolva00]

Maybe this ABI issue should be fixed for 9.0 ? Not sure how important, but
@hans maybe should track this one.

[craig.topper]

Add test cases. Change the type to vXi64 instead of vXf64. Add abi compatibility flag. Restrict to linux and freebsd.

[craig.topper]

More test check lines. Test the compatibility flag.

[hans]

In D64672#1623784, @xbolva00 wrote:

Maybe this ABI issue should be fixed for 9.0 ? Not sure how important, but
@hans maybe should track this one.

IIUC, this is not a new issue, so I'd prefer not trying to rush it in for llvm 9, and rather get it right for llvm 10 instead.

[RKSimon]

Please can you extend the test coverage to cover more vector sizes and cpu target features, not just avx512, and also add x86_64-scei-ps4 triple tests. Maybe 32-bit tests as well?

clang/include/clang/Basic/LangOptions.h

143 ↗

(On Diff #214540)

Add that this is just for Linux and NetBSD

[craig.topper]

In D64672#1653847, @RKSimon wrote:

Please can you extend the test coverage to cover more vector sizes and cpu target features, not just avx512, and also add x86_64-scei-ps4 triple tests. Maybe 32-bit tests as well?

Other than 256-bit what other size do you want?

[craig.topper]

Add more tests. Clarify which platforms are affected in LangOptions.h

[RKSimon]

Tests look great - please can you pre-commit them and update the patch to show the diff? Also, maybe call the test file x86-vec-i128.c and add a comment in the file describing PR42607?

[craig.topper]

In D64672#1654687, @RKSimon wrote:

Tests look great - please can you pre-commit them and update the patch to show the diff? Also, maybe call the test file x86-vec-i128.c and add a comment in the file describing PR42607?

How do you want me to show the diff? There a couple options. Three of the check lines have to be removed from the pre-commit since they use a command line option that doesn't exist. Do you want me to change the check lines that say NEWABI to use the old code? Or do you want me to manipulate the FileCheck command lines to use the OLDABI check lines?

[RKSimon]

In D64672#1654983, @craig.topper wrote:

In D64672#1654687, @RKSimon wrote:

Tests look great - please can you pre-commit them and update the patch to show the diff? Also, maybe call the test file x86-vec-i128.c and add a comment in the file describing PR42607?

How do you want me to show the diff? There a couple options. Three of the check lines have to be removed from the pre-commit since they use a command line option that doesn't exist. Do you want me to change the check lines that say NEWABI to use the old code? Or do you want me to manipulate the FileCheck command lines to use the OLDABI check lines?

How about CLANG9ABI and CLANG10ABI? And the patch just adds the -fclang-abi-compat=9 tests?

[craig.topper]

Change test name and adjust to the changes I think @RKSimon was asking for. I haven't commited the test yet. I'd like to verify that the before version of the test is how you would like it pre-committed

[probinson]

It looks to me like the patch does things the New Way only for Linux and NetBSD, so for PS4 backward compatibility I am okay with it.

[RKSimon]

LGTM - cheers

[RKSimon]

@craig.topper Wasn't this committed at rL371169 ?

[craig.topper]

Committed in r371169, but I forgot the Differential Revision line

clang/lib/CodeGen/TargetInfo.cpp

if (Size == 1 || Size == 8 || Size == 16 || Size == 32) {
         Current = SSE;
 
       // If this type crosses an eightbyte boundary, it should be
       // split.
       if (OffsetBase && OffsetBase != 64)
         Hi = Lo;
     } else if (Size == 128 ||
                (isNamedArg && Size <= getNativeVectorSizeForAVXABI(AVXLevel))) {
+      QualType ElementType = VT->getElementType();
+
+      // gcc passes 256 and 512 bit <X x int128> vectors in memory. :(
+      if (Size != 128 &&
+          (ElementType->isSpecificBuiltinType(BuiltinType::Int128) ||
+           ElementType->isSpecificBuiltinType(BuiltinType::UInt128)))
+        return;
+
       // Arguments of 256-bits are split into four eightbyte chunks. The
       // least significant one belongs to class SSE and all the others to class
       // SSEUP. The original Lo and Hi design considers that types can't be
       // greater than 128-bits, so a 64-bit split in Hi and Lo makes sense.
       // This design isn't correct for 256-bits, but since there're no cases
       // where the upper parts would need to be inspected, avoid adding
       // complexity and just consider Hi to match the 64-256 part.
       //

 }
 
 bool X86_64ABIInfo::IsIllegalVectorType(QualType Ty) const {
   if (const VectorType *VecTy = Ty->getAs<VectorType>()) {
     uint64_t Size = getContext().getTypeSize(VecTy);
     unsigned LargestVector = getNativeVectorSizeForAVXABI(AVXLevel);
     if (Size <= 64 || Size > LargestVector)
       return true;
+    QualType EltTy = VecTy->getElementType();
+    if (EltTy->isSpecificBuiltinType(BuiltinType::Int128) ||
+        EltTy->isSpecificBuiltinType(BuiltinType::UInt128))
+      return true;
   }
 
   return false;
 }
 
 ABIArgInfo X86_64ABIInfo::getIndirectResult(QualType Ty,
                                             unsigned freeIntRegs) const {
   // If this is a scalar LLVM value then assume LLVM will pass it in the right

 /// The ABI specifies that a value should be passed in a full vector XMM/YMM
 /// register. Pick an LLVM IR type that will be passed as a vector register.
 llvm::Type *X86_64ABIInfo::GetByteVectorType(QualType Ty) const {
   // Wrapper structs/arrays that only contain vectors are passed just like
   // vectors; strip them off if present.
   if (const Type *InnerTy = isSingleElementStruct(Ty, getContext()))
     Ty = QualType(InnerTy, 0);
 
+  // Don't pass vXi128 vectors in their native type, the backend can't
+  // legalize them.
   llvm::Type *IRType = CGT.ConvertType(Ty);
-  if (isa<llvm::VectorType>(IRType) ||
+  if ((isa<llvm::VectorType>(IRType) &&
+       !IRType->getVectorElementType()->isIntegerTy(128)) ||
       IRType->getTypeID() == llvm::Type::FP128TyID)
     return IRType;
 
   // We couldn't find the preferred IR vector type for 'Ty'.
   uint64_t Size = getContext().getTypeSize(Ty);
   assert((Size == 128 || Size == 256 || Size == 512) && "Invalid type found!");
 
   // Return a LLVM IR vector type based on the size of 'Ty'.