================
@@ -132,13 +132,35 @@ struct CIRRecordLowering final {
void calculateZeroInit();
CharUnits getSize(mlir::Type Ty) {
+ auto intTy = mlir::dyn_cast<cir::IntType>(Ty);
+ // Just like with getAlignment, the storage size of a bitint is the
+ // full-memory layout (adjusted for alignment), not just its width. So we
+ // have to special case that here too.
+ if (intTy && intTy.isBitInt())
+ return CharUnits::fromQuantity(intTy.storageBitwidth(dataLayout.layout) /
+ 8);
return CharUnits::fromQuantity(dataLayout.layout.getTypeSize(Ty));
}
CharUnits getSizeInBits(mlir::Type ty) {
return CharUnits::fromQuantity(dataLayout.layout.getTypeSizeInBits(ty));
}
- CharUnits getAlignment(mlir::Type Ty) {
- return CharUnits::fromQuantity(dataLayout.layout.getTypeABIAlignment(Ty));
+
+ CharUnits getAlignment(mlir::Type ty) {
+ CharUnits abiAlign =
+ CharUnits::fromQuantity(dataLayout.layout.getTypeABIAlignment(ty));
+ auto intTy = mlir::dyn_cast<cir::IntType>(ty);
+ if (!intTy || !intTy.isBitInt())
+ return abiAlign;
+
+ // _BitInt gets lowered to an LLVM-IR type of its size, which is going to
+ // have an incorrect alignment in LLVM if >64 bits. So we report THAT
+ // alignment here so that it gets laid out in a way that requires
+ // padding/packing to set the type alignments correctly.
+
+ mlir::Type storageTy = mlir::IntegerType::get(
----------------
andykaylor wrote:
This feels like a hack. Classic codegen doesn't have this problem because it
has already converted the i65 to an i128 by the time it gets here, so it's
getting the alignment of an i128. What we're returning here is not the
alignment of a _BitInt(N), despite what the function name implies. It's the
alignment requirement that the type imposes on the layout of the record.
CIRDataLayout doesn't have a clean alternative here like it does for the size.
https://github.com/llvm/llvm-project/pull/218008
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
