================
@@ -118,6 +124,37 @@ llvm::Type *CodeGenTypes::ConvertTypeForMem(QualType T, 
bool ForBitField) {
   return R;
 }
 
+bool CodeGenTypes::LLVMTypeLayoutMatchesAST(QualType ASTTy,
+                                            llvm::Type *LLVMTy) {
+  CharUnits ASTSize = Context.getTypeSizeInChars(ASTTy);
+  CharUnits LLVMSize =
+      CharUnits::fromQuantity(getDataLayout().getTypeAllocSize(LLVMTy));
+  return ASTSize == LLVMSize;
+}
+
+llvm::Type *CodeGenTypes::convertTypeForLoadStore(QualType T,
+                                                  llvm::Type *LLVMTy) {
+  if (!LLVMTy)
+    LLVMTy = ConvertType(T);
+
+  if (!T->isBitIntType() && LLVMTy->isIntegerTy(1))
+    return llvm::IntegerType::get(getLLVMContext(),
+                                  (unsigned)Context.getTypeSize(T));
+
+  if (T->isBitIntType()) {
+    llvm::Type *R = ConvertType(T);
+    if (!LLVMTypeLayoutMatchesAST(T, R))
+      return llvm::Type::getIntNTy(
+          getLLVMContext(), Context.getTypeSizeInChars(T).getQuantity() * 8);
----------------
momchil-velikov wrote:

Getting back to this...

> I wonder making it unconditional that requires to have different in-memory 
> type for all _BitInt types?

The in-memory representation is a whole number of bytes, so in general the 
number of in-memory bits will be different from the declared number on a 
`_BitInt` type.

If you have `_BitInt(K)` and a load/store type `iN`, then loading/storing `iK` 
won't necessarily write to the same bytes as loading/storing `iN` would. That 
means we won't be writing to all the bytes of the in-memory representation 
which might be incorrect (e.g. for AArch32 ABI which requires padding bits to 
be sign- or zero- extended). It can also be inefficient, because LLVM requires 
memory accesses to be the minimum number of bytes sufficient to hold an `iK` - 
e.g. `i17` will end up as a load store of `i16` followed by a load store of 
`i8`, whereas the in-memory representation is 4 bytes  and can be accesses as a 
single `i32`.



https://github.com/llvm/llvm-project/pull/91364
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to