[PATCH] D124435: [X86] Always extend the integer parameters in callee

[LiuChen via Phabricator via cfe-commits]

LiuChen3 added inline comments.


================
Comment at: clang/docs/ClangCommandLineReference.rst:2988-2992
+.. option:: -mconservative-extend
+Always extend the integer parameter both in the callee and caller.
+
+.. option:: -mno-conservative-extend
+Keep the original integer parameter passing behavior.
----------------
rjmccall wrote:
> pengfei wrote:
> > Combine like others?
> How about:
> 
> ```
> In the past, Clang passed small integer arguments on certain targets using a
> parameter convention in which the caller was assumed to have sign-extended
> or zero-extended the argument to a certain width.  This convention was not
> conformant with the documented ABI on these platforms, which does not
> require the caller to perform this extension.  Clang no longer assumes that
> callers perform this extension, but for compatibility with code compiled by
> previous releases of Clang, Clang defaults to still extending the argument in the
> caller.  `-mno-conservative-extend` disables this, which may improve
> performance and code size if compatibility with old versions of Clang is not
> required.
> 
> This affects most 32-bit and 64-bit x86 targets, except:
> - Windows, which Clang has never assumed extension on
> - Apple platforms, which use a non-standard ABI that unconditionally assumes extension
> ```
> 
> Note that I need to check that that's what Apple actually wants to do.  You should also reach out to the Sony folks to see what they want to do, but I expect that it's to assume extension unconditionally.
Thanks a lot! It's much clearer.
Just a small correction for windows: only windows64 is not affected.


================
Comment at: clang/include/clang/CodeGen/CGFunctionInfo.h:333
   bool canHaveCoerceToType() const {
-    return isDirect() || isExtend() || isCoerceAndExpand();
+    return isDirect() || isExtend() || isCoerceAndExpand() ||
+           isConservativeExtend();
----------------
pengfei wrote:
> Can we move it to `isExtend`? e.g. `TheKind == Expand | TheKind == ConservativeExtend`
I prefer to set it alone as it is a different `Kind` from `Extend`. 


================
Comment at: clang/lib/CodeGen/CGCall.cpp:2451
+      // attribute to the callee.
+      if (AttrOnCallSite || AI.getKind() == ABIArgInfo::Extend) {
+        if (AI.isSignExt())
----------------
pengfei wrote:
> LiuChen3 wrote:
> > pengfei wrote:
> > > Does the change affect Windows? Seems Win64 doesn't extend on caller. https://godbolt.org/z/c95hvvsWf
> > No.  This patch didn't nothing for Win64 ABI.
> But I found some Windows tests are affected?
I checked it again and it should be that only win32 is affected.


================
Comment at: clang/lib/CodeGen/TargetInfo.cpp:1938
+    return IsConservativeExtend ? ABIArgInfo::getConservativeExtend(Ty)
+                                : ABIArgInfo::getExtend(Ty);
   }
----------------
rjmccall wrote:
> This looks wrong.  In non-`ConservativeExtend` mode, we don't get to assume extension at all and should use `Direct`, right?
As I understand it, `Direct` means do nothing with the parameters. Caller won't do the extension and callee can't assume the parameter is correct. This makes new clang behave in the opposite way to currently clang behavior, which will cause incompatibility issue. e.g:
https://godbolt.org/z/d3Peq4nsG


================
Comment at: clang/lib/CodeGen/TargetInfo.cpp:3818
+          return ABIArgInfo::getConservativeExtend(Ty);
         return ABIArgInfo::getExtend(Ty);
+      }
----------------
rjmccall wrote:
> Same comment: this should use `Direct` when we're not in `ConservativeExtend` mode, right?
Same as above.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D124435/new/

https://reviews.llvm.org/D124435