[PATCH] D91338: [X86] Zero-extend pointers to i64 for x86_64

Harald van Dijk via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat Nov 14 00:49:55 PST 2020


hvdijk added a comment.

In D91338#2395497 <https://reviews.llvm.org/D91338#2395497>, @pengfei wrote:

> Hi Harald, thanks for thoroughly answering my questions. I still have doubts intention of this patch. Is there any bug related to it?

I run an x32 system. Things work well for things built with GCC, but break badly when using LLVM, including crashes of pretty much any non-trivial Rust application such as ripgrep or the Rust compiler itself, because the ABI as implemented is incompatible between GCC and LLVM, as GCC-generated code will sometimes assume that the high bits of pointer parameters have been zeroed out as required by the ABI. This is especially visible when using Rust applications, as the Rust compiler is LLVM-based but most of the rest of my system is built with GCC. Pretty much any non-trivial Rust application crashes, for instance ripgrep, or the Rust compiler itself.

> IMHO, the ILP32 mode is designed for performance which always assumes the address bit 63~32 all zero and uses 32 bits register to reduce code size.

Using 32 bits registers is not always possible, and when possible increases, not reduces, code size. When instructions can take either a 32-bit register or a 64-bit register, the 64-bit register is what you get by default, the 32-bit register requires an extra byte. For instance, `mov (%edi),%eax` is encoded as 0x67 0x8B 0x07, but `mov (%rdi), %eax` is encoded as just 0x8B 0x07. The idea of the ABI, I believe, is that called functions should be able to use 64 bit registers for memory operations. That said, I have not done any work to ensure that 64-bit registers are used where possible; both GCC and LLVM with my patch do generate code that unnecessarily uses 32-bit registers.


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

https://reviews.llvm.org/D91338



More information about the llvm-commits mailing list