武汉网站建设哪家好目前主流搜索引擎是哪种
原文
长期以来,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)`的偏移:2`Foo`对齐:2`栏`中`b(u64)`的偏移:8`bar`对齐:8
看到,在一个结构中,总是在它的偏移是其对齐的倍数位置放置一个类型,即使表明未使用的空间,当不使用repr(C)时,Rust默认最小化它.
这些数字不是任意的;应用二进制接口(ABI)说明了它们应该是什么.在系统V(Unix&Linux)的x86-64psABI(处理器相关的ABI)中,图3.1:标量类型准确地告诉了应该如何表示原语:
C型 | Rust等价 | sizeof | 对齐(字节) |
|---|---|---|---|
符 | i8 | 1 | 1 |
正符 | u8 | 1 | 1 |
| 短 | i16 | 2 | 2 |
| 正短 | u16 | 2 | 2 |
| 长 | i64 | 8 | 8 |
正长 | u64 | 8 | 8 |
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 | 对齐(字节) |
|---|---|---|---|
__int128 | i128 | 16 | 16 |
正__int128 | u128 | 16 | 16 |
表明,这并不是因为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月发布)完全兼容.