[flang-commits] [flang] [flang] Create TBAA subtree for COMMON block variables. (PR #156558)

[via flang-commits]

================
@@ -57,12 +62,131 @@ static llvm::cl::opt<unsigned> localAllocsThreshold(
 
 namespace {
 
+// Return the size and alignment (in bytes) for the given type.
+// TODO: this must be combined with DebugTypeGenerator::getFieldSizeAndAlign().
+// We'd better move fir::LLVMTypeConverter out of the FIRCodeGen component.
+static std::pair<std::uint64_t, unsigned short>
+getTypeSizeAndAlignment(mlir::Type type,
+                        fir::LLVMTypeConverter &llvmTypeConverter) {
+  mlir::Type llvmTy;
+  if (auto boxTy = mlir::dyn_cast_if_present<fir::BaseBoxType>(type))
+    llvmTy = llvmTypeConverter.convertBoxTypeAsStruct(boxTy, getBoxRank(boxTy));
+  else
+    llvmTy = llvmTypeConverter.convertType(type);
----------------
jeanPerier wrote:

Pedantically speaking, fir.boxproc abstraction was meant to allow lowering it to a tuple, which would be a valid and useful abstraction for procedure pointers (but not dummy procedures) to avoid creating executable trampolines when making pointers out internal procedures.

So fir.boxproc has its own codegen to FIR before lowering to LLVM. Hardcoding the type lowering in the LLVMTypeConverter and using that before the fir.boxproc codegen bypasses this completely.

However my point is pedantic in the sense that this is not the codegen chosen/used by flang, and at least for fir.boxproc that may be visible to other compilation units (such as external procedure arguments and derived type members), it is not something the fir.boxproc codegen could decide to change on the fly (it needs to be in sync with semantic offsets).

I feel the ideal would be to reconcile/unify/or link the LLVMTypeConverter and [BoxprocTypeRewriter](https://github.com/llvm/llvm-project/blob/44b779526036a62aa2f7c5285a51f5c043805c33/flang/lib/Optimizer/CodeGen/BoxedProcedure.cpp#L42) to avoid discrepancies at the FIR level.

I would be fine with just some FIRType helper used in both converter to connect the dots (although the BoxprocTypeRewriter is not using a pointer type, it is using the inner FunctionType and recursively converting the signature, so this may not be direct).

Another solution could be to run the TBAA pass after the BoxedProcedure if that makes any sense.

Last point is that procedure pointers and derived types with procedure pointers are forbidden in COMMON BLOCK and EQUIVALENCE (C8123 and C8110 in F2023). I am not sure if this is enforced in semantics.

https://github.com/llvm/llvm-project/pull/156558