[flang-commits] [flang] [flang] Fix RecordType sizes, TRANSFER lowering, and BIND(C) ABI on SystemZ/PPC64le (PR #220377)
via flang-commits
flang-commits at lists.llvm.org
Thu Sep 10 01:30:54 PDT 2026
================
@@ -1661,15 +1663,40 @@ fir::getTypeSizeAndAlignment(mlir::Location loc, mlir::Type ty,
if (auto recTy = mlir::dyn_cast<fir::RecordType>(ty)) {
std::uint64_t size = 0;
unsigned short align = 1;
+ if (recTy.isPacked()) {
+ // LLVM packed structs (<{ ... }>) place fields back-to-back with no
+ // inter-field alignment padding and no tail padding. Each component
+ // still occupies its allocation size (llvm::alignTo(storeSize, ABI
+ // alignment)), because LLVM's packed StructLayout advances by
+ // getTypeAllocSize, not getTypeStoreSize. For example, x86 f80 has
----------------
MattPD wrote:
Could we keep the reasoning in `Changes` but drop the file-by-file walkthrough? The helper inventory and branch-by-branch account mostly repeat the diff.
I'd keep these explanations:
- Separate size query: Keeping representation width separate from allocation extent preserves the previous inline/runtime choices for the illustrated unpacked `TRANSFER` cases.
- Aligned temporary: Equal byte widths don't guarantee sufficient address alignment for the result load.
- Bytewise copy: An aggregate store can discard inter-field padding even in an aligned temporary.
I'd also keep the ABI consequences and recompilation warning with that reasoning. In the SystemZ and PPC64le examples, the record layout already included the padding, but the size query used for argument classification was wrong.
https://github.com/llvm/llvm-project/pull/220377
More information about the flang-commits
mailing list