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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
