[PATCH] D72742: Don't assume promotable integers are zero/sign-extended already in x86-64 ABI.

Reid Kleckner via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jan 15 14:06:21 PST 2020


rnk added a comment.

In D72742#1822709 <https://reviews.llvm.org/D72742#1822709>, @emilio wrote:

> GCC does avoid the zero-extension on the caller sometimes, when not required by the language and when its optimizer finds it suitable.


I believe at the time, faced with ambiguity in the document, experiments were done to try to uncover what GCC actually did in practice. I guess LLVM settled on the "things are extended to 32-bits" model.

This change seems like it has backwards compatibility concerns with clang. If new clang stops extending things and it calls old clang code, won't that cause breakages? Based on the test code updates, it seems like you are updating both call sites and function prototypes. Won't that be problematic for the users that care about ABI stability over GCC ABI compatibility?



================
Comment at: clang/test/CodeGen/2007-06-18-SextAttrAggregate.c:11
 
+// Same for AMD64's PSABI
+
----------------
This test was originally added for x86_64, see the bug:
https://bugs.llvm.org/show_bug.cgi?id=1513

It needs to be updated.


================
Comment at: clang/test/CodeGenCXX/const-init-cxx11.cpp:536
   void test() {
-    // CHECK: call void @_ZN13InitFromConst7consumeIbEEvT_(i1 zeroext true)
+    // FIXME: This should probably be:
+    // call void @_ZN13InitFromConst7consumeIbEEvT_(i1 zeroext true)
----------------
I agree it would be nice to avoid emitting these coercions through memory for such simple cases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72742





More information about the llvm-commits mailing list