PhantomData fields in repr(C) structs change ABI on aarch64

[glandium]

Take this testcase:

#[repr(C)]
pub struct Foo {
    pub a: f32,
    pub b: f32,
}

#[no_mangle]
pub extern "C" fn foo(f: Foo) -> bool {
    f.a != f.b
}

#[repr(C)]
pub struct Bar {
    pub a: f32,
    pub b: f32,
    pub _unit: std::marker::PhantomData<()>,
}

#[no_mangle]
pub extern "C" fn bar(f: Bar) -> bool {
    f.a != f.b
}

Compile with:

rustc +nightly --target=aarch64-pc-windows-msvc --emit asm test.rs --crate-type staticlib -C opt-level=2

And check the output test.s file:

	.text
	.section	.text,"xr",one_only,foo
	.globl	foo
	.p2align	2
foo:
.seh_proc foo
	fcmp	s0, s1
	cset	w0, ne
	ret
	.section	.xdata,"dr",associative,foo
	.seh_handlerdata
	.section	.text,"xr",one_only,foo
	.seh_endproc

	.section	.text,"xr",one_only,bar
	.globl	bar
	.p2align	2
bar:
.seh_proc bar
	lsr	x8, x0, #32
	fmov	s0, w0
	fmov	s1, w8
	fcmp	s0, s1
	cset	w0, ne
	ret
	.section	.xdata,"dr",associative,bar
	.seh_handlerdata
	.section	.text,"xr",one_only,bar
	.seh_endproc

One would expect foo and bar having the same code, but that's not the case here.

This is the root cause of https://bugzilla.mozilla.org/show_bug.cgi?id=1512519

[glandium]

Here is the non-optimized llvm-ir:

target datalayout = "e-m:w-p:64:64-i32:32-i64:64-i128:128-n32:64-S128"
target triple = "aarch64-pc-windows-msvc"

%Bar = type { [0 x i32], float, [0 x i32], float, [0 x i8], %"core::marker::PhantomData<()>", [0 x i8] }
%"core::marker::PhantomData<()>" = type {}

; Function Attrs: nounwind uwtable
define zeroext i1 @foo([2 x float]) unnamed_addr #0 {
start:
  %abi_cast = alloca [2 x float], align 4
  %f = alloca { float, float }, align 4
  store [2 x float] %0, [2 x float]* %abi_cast, align 4
  %1 = bitcast { float, float }* %f to i8* 
  %2 = bitcast [2 x float]* %abi_cast to i8* 
  call void @llvm.memcpy.p0i8.p0i8.i64(i8* align 4 %1, i8* align 4 %2, i64 8, i1 false)
  %3 = bitcast { float, float }* %f to float*
  %4 = load float, float* %3, align 4
  %5 = getelementptr inbounds { float, float }, { float, float }* %f, i32 0, i32 1
  %6 = load float, float* %5, align 4
  %7 = fcmp une float %4, %6
  ret i1 %7
}

; Function Attrs: nounwind uwtable
define zeroext i1 @bar(i64) unnamed_addr #0 {
start:
  %abi_cast = alloca i64, align 8
  %f = alloca %Bar, align 4
  store i64 %0, i64* %abi_cast, align 8
  %1 = bitcast %Bar* %f to i8* 
  %2 = bitcast i64* %abi_cast to i8* 
  call void @llvm.memcpy.p0i8.p0i8.i64(i8* align 4 %1, i8* align 8 %2, i64 8, i1 false)
  %3 = bitcast %Bar* %f to float*
  %4 = load float, float* %3, align 4
  %5 = getelementptr inbounds %Bar, %Bar* %f, i32 0, i32 3
  %6 = load float, float* %5, align 4
  %7 = fcmp une float %4, %6
  ret i1 %7
}

For reference, the llvm-ir for the same source code, for x86_64:

target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

%Bar = type { [0 x i32], float, [0 x i32], float, [0 x i8], %"core::marker::PhantomData<()>", [0 x i8] }
%"core::marker::PhantomData<()>" = type {}

; Function Attrs: nounwind nonlazybind uwtable
define zeroext i1 @foo(double) unnamed_addr #0 {
start:
  %abi_cast = alloca double, align 8
  %f = alloca { float, float }, align 4
  store double %0, double* %abi_cast, align 8
  %1 = bitcast { float, float }* %f to i8* 
  %2 = bitcast double* %abi_cast to i8* 
  call void @llvm.memcpy.p0i8.p0i8.i64(i8* align 4 %1, i8* align 8 %2, i64 8, i1 false)
  %3 = bitcast { float, float }* %f to float*
  %4 = load float, float* %3, align 4
  %5 = getelementptr inbounds { float, float }, { float, float }* %f, i32 0, i32 1
  %6 = load float, float* %5, align 4
  %7 = fcmp une float %4, %6
  ret i1 %7
}

; Function Attrs: nounwind nonlazybind uwtable
define zeroext i1 @bar(double) unnamed_addr #0 {
start:
  %abi_cast = alloca double, align 8
  %f = alloca %Bar, align 4
  store double %0, double* %abi_cast, align 8
  %1 = bitcast %Bar* %f to i8* 
  %2 = bitcast double* %abi_cast to i8* 
  call void @llvm.memcpy.p0i8.p0i8.i64(i8* align 4 %1, i8* align 8 %2, i64 8, i1 false)
  %3 = bitcast %Bar* %f to float*
  %4 = load float, float* %3, align 4
  %5 = getelementptr inbounds %Bar, %Bar* %f, i32 0, i32 3
  %6 = load float, float* %5, align 4
  %7 = fcmp une float %4, %6
  ret i1 %7
}

The notable difference is i64 vs. double. Note that the above is the output of --emit llvm-ir with no opt-level. I don't know if that matches what rustc passes to llvm. (I don't remember what the option to output the llvm-ir before/after all passes is)

[glandium]

It's interesting to note that x86-64 takes the two floats as a single double, while aarch64 takes two floats, but the main problem here is that bar is taking an i64 instead of two floats on aarch64...

[glandium]

BTW, this also happens on aarch64-unknown-linux-gnu, and I've now confirmed that the IR before the first optimization pass is the same.

[parched]

This happens because homogeneous aggregates are treated differently in the PCS compared to inhomogeneous aggregates. It depends how zero sized types are defined to behave in #[repr(C)] types as to whether this is a bug or not. Should they be completely ignored?

[emilio]

Yes, or at least that's the assumption that all of bindgen / cbindgen / the improper_ctypes lint make.

[nikomatsakis]

Nominating: this is likely to be a very high priority for FF over the next month or so, and if we can get a fix in now that will be a big win.

[parched]

FWIW the code to fix is here. The question is, should just PhantomData be ignored or all ZSTs or just ZSTs with aligmnent=1?

EDIT: or actually here but perhaps PhantomData should be stripped out of the type much earlier.

[glandium]

There's nothing platform-dependent in that code, how come this only affects aarch64?

Edit: Oh, right #56877 (comment)

[pnkfelix]

discussed at T-compiler meeting. P-high. assigning to self to make sure it doesn't get lost. (@nikomatsakis says "maybe we're close to a fix", which I assume is based on the comment thread here).