Win64 ABI shouldn't extend integer type arguments.

[jlerouge]

Summary

MSVC doesn't extend integer types smaller than 64bit, so to preserve
binary compatibility, clang shouldn't either.

For example, the following C code built with MSVC:

unsigned test(unsigned v);
unsigned foobar(unsigned short);
int main() { return test(0xffffffff) + foobar(28); }

Produces the following:

0000000000000004: B9 FF FF FF FF     mov         ecx,0FFFFFFFFh
0000000000000009: E8 00 00 00 00     call        test
000000000000000E: 89 44 24 20        mov         dword ptr [rsp+20h],eax
0000000000000012: 66 B9 1C 00        mov         cx,1Ch
0000000000000016: E8 00 00 00 00     call        foobar

And as you can see, when setting up the call to foobar, only cx is overwritten.

If foobar is compiled with clang, then the zero extension added by clang means
the rest of the register, which contains garbage, could be used.

For example if foobar is:

unsigned foobar(unsigned short v) {

return v;

}

Compiled with clang -fomit-frame-pointer -O3 gives the following assembly:

foobar:

0000000000000000: 89 C8              mov         eax,ecx
0000000000000002: C3                 ret

And that function would return garbage because the 16 most significant bits of
ecx still contain garbage from the first call.

With this change, the code for that function is now:

foobar:

0000000000000000: 0F B7 C1           movzx       eax,cx
0000000000000003: C3                 ret

[majnemer]

I think this deserves more testing than just adding another target to an XFAIL line.

[jlerouge]

Add an explicit test.

Just check that clang doesn't add zext/sext attributes on small integer types.

[rnk]

lgtm

For the record, mingw64 GCC does the same thing:

_foobar:
      .seh_endprologue
      movzwl  %cx, %eax
      ret
      .seh_endproc

test/CodeGen/2007-06-18-SextAttrAggregate.c

2

Let's just give this an explicit x86 triple.

[jlerouge]

One more update to unbreak CodeGenCXX/microsoft-abi-member-pointers.cpp in r216507. We can preserve the zeroext on bool types, that still gives us code compatible with MSVC, since it's only extending to 8bits.

lib/CodeGen/TargetInfo.cpp

if (RT || Ty->isMemberPointerType()) {
     // not 1, 2, 4, or 8 bytes, must be passed by reference."
     if (Size > 64 || !llvm::isPowerOf2_64(Size))
       return ABIArgInfo::getIndirect(0, /*ByVal=*/false);
 
     // Otherwise, coerce it to a small integer.
     return ABIArgInfo::getDirect(llvm::IntegerType::get(getVMContext(), Size));
   }
 
-  if (Ty->isPromotableIntegerType())
-    return ABIArgInfo::getExtend();
-
   return ABIArgInfo::getDirect();
 }
 
 void WinX86_64ABIInfo::computeInfo(CGFunctionInfo &FI) const {
   if (!getCXXABI().classifyReturnType(FI))
     FI.getReturnInfo() = classify(FI.getReturnType(), true);
 
   for (auto &I : FI.arguments())

test/CodeGen/2007-06-18-SextAttrAggregate.c

 // RUN: %clang_cc1 %s -o - -emit-llvm | FileCheck %s
-// XFAIL: aarch64, arm64
+// XFAIL: aarch64, arm64, x86_64-pc-win32
 
 // PR1513
 
 // AArch64 ABI actually requires the reverse of what this is testing: the callee
 // does any extensions and remaining bits are unspecified.
 
+// Win64 ABI does expect extensions for type smaller than 64bits.
+
 // Technically this test wasn't written to test that feature, but it's a
 // valuable check nevertheless.
 
 struct s{
 long a;
 long b;
 };
 
 void f(struct s a, char *b, signed char C) {
   // CHECK: i8 signext
 
 }

test/CodeGen/x86_64-arguments-win32.c

+// RUN: %clang_cc1 -w -triple x86_64-pc-win32 -emit-llvm -o - %s | FileCheck %s
+
+// To be ABI compatible with code generated by MSVC, there shouldn't be any
+// sign/zero extensions on types smaller than 64bit.
+
+// CHECK-LABEL: define void @f1(i8 %a)
+void f1(char a) {}
+
+// CHECK-LABEL: define void @f2(i8 %a)
+void f2(unsigned char a) {}
+
+// CHECK-LABEL: define void @f3(i16 %a)
+void f3(short a) {}
+
+// CHECK-LABEL: define void @f4(i16 %a)
+void f4(unsigned short a) {}