[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