compiler: Fix "power alignment" problems on AIX

[workingjubilee]

Hello, this is a localized rustc-focused fix for the AIX "power alignment" issue. It does not fix upstream because I expect that to be a more annoying experience and would take some time to propagate into the release. I mostly wish to remove the "power alignment" lint so we do not have to work it into updates to the "improper-ctypes" lint, but it feels wrong to do so without actually fixing the codegen issue, especially since it's such a small change.

cc @daltenty @gilamn5tr @mustartt @amy-kwan Can you confirm whether this change allows rustc to do FFI correctly with C code compiled using the default AIX ABI?

[rustbot]

r? @wesleywiser

rustbot has assigned @wesleywiser.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

These commits modify compiler targets.
(See the Target Tier Policy.)

[RalfJung]

It does not fix upstream

I assume you are referring to llvm/llvm-project#133599 here? Always good to leave some cross-references. :)

Please also add comments in the code referencing that (both in the aix target triple, and the special exception for the data layout consistency check). Right now, just looking at the code after applying this diff, one would have a very hard time figuring out what happens.

[workingjubilee]

aye aye capitan

[RalfJung]

As discussed on IRLO, as-is this patch would make some types more correct and others less correct. Hard to say whether that's overall a net positive...

[workingjubilee]

It does fix every type that doesn't have f64 as its recursive-first-element, so I'm feeling pretty good about it alone.

[RalfJung]

Are there really more types with f64 in some later field vs the first field? Also, for the later field case we at least had a lint...

[beetrees]

Not all types which start with f64 would be affected, just those that also need at least 4 bytes of padding at the end of the struct, all of which could easily be fixed by adding _padding: MaybeUninit<u32> at the end of the relevant struct (a lint could be added for this case with a suggestion if desired). Compared to the #112480-like issues that giving f64 an alignment of 8 causes, I think this PR is a definite improvement.

[workingjubilee]

Are there really more types with f64 in some later field vs the first field?

I think so, when we're considering that it includes all nested aggregates?

Yes, the problem after this patch is now "possible-to-fix-in-bindgen"-tier.

[RalfJung]

all of which could easily be fixed by adding _padding: MaybeUninit at the end of the relevant struct

Ah, that's a good point.