fix #29718, union field alignment

[JeffBezanson]

No description provided.

[quinnj]

So is the bug only hit in the case where there were enough fields to require alignment? Or with an unfortunate choice of fields prior to an isbits Union field to cause the misalignment?

[vtjnash]

This looks correct, but is a bit more pessimistic than it necessarily needs to be. The only caller that needs the more pessimistic result is julia_struct_to_llvm, so we can instead just remove the first branch from julia_struct_to_llvm that calls this, and instead unconditionally uses the jl_islayout_inline computation—that's still slightly pessimistic for alignment in rare cases (we could use al = std::min(al, fsz)), but the jl_islayout_inline alignment computation result might be a better match for later usage (better for SROA) anyways.

[vtjnash]

@quinnj, the correct representation of the type was { [i16 * 1], i8 }, so this only hits when we are at a byte boundary where the actual alignment guarantee exceeds the minimum required (we had accidentally instead emitted { [i64 * 0], i8, i8, i8 }).

[JeffBezanson]

Better?

[vtjnash]

Remove pessimization of jl_field_align?

MWE can be added to the existing UnionFieldN list of tests. The smallest type that should exhibit this mis-behavior is:

struct UnionField
    alignment::Int32
    padding::NTuple{3, UInt8}
    #= implicit-padding::UInt8 =#
    maybe_val::Union{UInt16, Nothing} # offset = 8, align = 8, size = 2
end