哪些企业网站使用水墨风格,个人申请营业执照流程,辽阳网站推广,安徽建海建设工程有限公司网站原文
长期以来,Rust在x86-32和x86-64架构上128位整数的对齐与C语言不一致.最近已解决此问题,但该修复带来了一些值得注意的效果.
作为用户,除非如下,否则不用担心: 1,假设i128/u128对齐,而不是用align_of 2,忽略improper_ctypes*检查,并在FFI中使用这些类.
除x86-32和x86-64…原文
长期以来,Rust在x86-32和x86-64架构上128位整数的对齐与C语言不一致.最近已解决此问题,但该修复带来了一些值得注意的效果.
作为用户,除非如下,否则不用担心: 1,假设i128/u128对齐,而不是用align_of 2,忽略improper_ctypes*检查,并在FFI中使用这些类.
除x86-32和x86-64外,其他架构不变.如果你的代码大量使用128位整数,会注意到运行时性能提高,但可能会增加内存使用.
背景
数据类型有两个与内存中的排列方式有关的内部值:大小和对齐.类型的大小是它在内存中消费的空间量,对齐指定了允许在哪些地址放置它.
像原语此类简单类型的大小一般是无歧义的,是它们所表示的数据的没有填充(未使用的空间)的确切大小.如,i64的大小总是为64位或8字节.
但是,对齐可能会有所不同.可在(1字节对齐)任意内存地址中保存8字节整数,但大多数64位计算机如果按8的倍数(8字节对齐)保存,则会取得最佳性能.
因此,与其他语言一样,Rust中的原语默认有该最有效的对齐.在创建复合类型时可见该效果:
use core::mem::{align_of, offset_of};
#[repr(C)]
struct Foo {a: u8, //1字节对齐b: u16, //2字节对齐
}
#[repr(C)]
struct Bar {a: u8, //1字节对齐b: u64, //8字节对齐
}
println!(Offset of b (u16) in Foo: {}, offset_of!(Foo, b));
println!(Alignment of Foo: {}, align_of::Foo());
println!(Offset of b (u64) in Bar: {}, offset_of!(Bar, b));
println!(Alignment of Bar: {}, align_of::Bar());输出: Foo中b(u16)的偏移:2Foo对齐:2栏中b(u64)的偏移:8bar对齐:8看到,在一个结构中,总是在它的偏移是其对齐的倍数位置放置一个类型,即使表明未使用的空间,当不使用repr(C)时,Rust默认最小化它.
这些数字不是任意的;应用二进制接口(ABI)说明了它们应该是什么.在系统V(UnixLinux)的x86-64psABI(处理器相关的ABI)中,图3.1:标量类型准确地告诉了应该如何表示原语:
C型Rust等价sizeof对齐(字节)符i811正符u811短i1622正短u1622长i6488正长u6488
ABI仅指定了C类型,但Rust在兼容和性能优势方面都遵守相同定义.
错误的对齐问题
如果两个实现在数据类型的对齐上有分歧,则无法可靠地共享包含该类型的数据.Rust对128位类型的对齐不一致:
println!(alignment of i128: {}, align_of::i128());
//rustc1.76.0版本
// i128对齐:8
printf(alignment of __int128: %zu\n, _Alignof(__int128));
//GCC版本13.2
// __int128对齐:16
// Clang17.0.1
// __int128对齐:16回头看一下psABI,可见Rust在此的对齐是错误的:
C型Rust等价sizeof对齐(字节)__int128i1281616正__int128u1281616
表明,这并不是因为Rust积极地做错了什么:原语的布局来自Rust和Clang等语言使用的LLVMcodegen后端,且它有硬编码为8字节的i128对齐.
Clang使用正确的对齐只是因为变通,即在把类型交给LLVM前,手动按16字节设置对齐.这解决了布局问题,但也是其他一些小问题的根源.
Rust无此手动调整,因此在https://github.com/rustlang/rust/issues/54341上报告了它.
调用约定问题
还有一个问题:LLVM在按函数参数传递128位整数时,并不总是正确.在发现它与Rust相关前,这是LLVM中的一个已知问题.
调用函数时,会在寄存器中传递参数,直到没有更多的槽,然后会溢出到栈中(程序的内存).
ABI在3.2.3传递参数一节中,也告诉了该怎么做:
__int128类型的参数与INTEGER操作相同,但它们不适合一个通用寄存器,而是需要两个寄存器.为了分类,按如下实现对待__int128:
typedef struct {long low, high;
} __int128;但在内存中保存的__int128类型的参数必须在16字节边界上对齐.
可手动实现调用约定来试此操作.在下面C示例中,用内联汇编按val为0x11223344556677889900aabbccddeeff值,来调用foo(0xaf,val,val,val).
x86-64使用RDI,RSI,RDX,RCX,R8和R9寄存器,来按顺序传递函数参数.每个寄存器适合一个字(64位),不合适的都压进栈中.
/*https://godbolt.org/z/5c8cb5cxs的完整示例*/
/*要查看问题,需要一个内边距值来搞砸参数对齐*/
void foo(char pad, __int128 a, __int128 b, __int128 c) {printf(%#x\n, pad 0xff);print_i128(a);print_i128(b);print_i128(c);
}
int main() {asm(/*加载适合寄存器的参数*/movl $0xaf,%edi\n\t/*第1个槽位(EDI):填充符(EDI是*与RDI相同,只是访问大小较小)*/movq $0x9900aabbccddeeff,%rsi\n\t/*第2个槽(RSI):a的下半部分*/movq $0x1122334455667788,%rdx\n\t/*第3个槽(RDX):a的上半部分*/movq $0x9900aabbccddeeff,%rcx\n\t/*第4个槽(RCX):b的下半部分*/movq $0x1122334455667788,%r8\n\t/*第5个槽位(r8):b的上半部分*/movq $0xdeadbeef4c0ffee0,%r9\n\t/*第6个槽(R9):应该未使用,但来欺骗Clang!*//*重用保存的寄存器来加载栈*/pushq %rdx\n\t/*在栈上传递c的上半部分*/pushq %rsi\n\t/*在栈上传递c的下半部分*/call foo\n\t/*调用函数*/addq $16,%rsp\n\t/*重置栈*/);
}使用GCC运行上述操作打印以下期望输出: 0xaf0x11223344556677889900aabbccddeeff0x11223344556677889900aabbccddeeff0x11223344556677889900aabbccddeeff但是使用Clang17打印: 0xaf0x11223344556677889900aabbccddeeff0x11223344556677889900aabbccddeeff0x9900aabbccddeeffdeadbeef4c0ffee0^^^^^^^^^^^^^^^^这应该是下半部分^^^^^^^^^^^^^^^^很熟悉惊喜!
这说明了第二个问题:LLVM期望i128在可能时一半在寄存器中传递,一半在栈上传递,但ABI禁止这样做.
因为该行为来自LLVM且没有合理的解决方法,因此这在Clang和Rust中都是一个问题.
方法
NikitaPopov修复了D158169的调用约定问题.这两项更改都已纳入LLVM18,即所有相关的ABI问题都使用在此版本的Clang和Rust中得到解决.
因为这些更改,Rust现在生成正确的对齐:
println!(alignment of i128: {}, align_of::i128());
//rustc1.77.0版本i128对齐:16
如上,ABI指定数据类型对齐的部分原因是因为它在该架构上效率更高.更改手动对齐的初始性能运行,表明大大改进了编译器性能(严重依赖128位整数来处理整数文字).
增加对齐的缺点是在内存中复合类型并不总是很好地组合在一起,从而导致使用量增加.可惜,即需要牺牲一些性能优势,以避免增加内存成本.
兼容
总之,使用LLVM18(默认版本从1.78开始)的Rust的i128和u128将与版本的GCC及Clang18及更高版本(2024年3月发布)完全兼容.
