[flang-commits] [flang] [flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (PR #69692)

[via flang-commits]

================
@@ -328,16 +320,15 @@ mlir::Type LLVMTypeConverter::convertSequenceType(SequenceType seq) const {
     if (!seq.hasDynamicExtents())
       return baseTy;
   }
-  return mlir::LLVM::LLVMPointerType::get(baseTy);
+  return baseTy;
----------------
jeanPerier wrote:

Its actually guaranteed to _not be_ a pointer type :) Yeah, seeing the change only makes this very weird....

Basically FIR has this fir.array type to describe array types, the extents may be constants or not.

A fir.array with non compile time constant extents is not meant to be used as the type of an SSA value (unless of course in hacky type conversion test like below...). SSA values with dynamic extents must be in memory in fir, and the fir.array type will be wrapped in a memory type (fir.ptr<fir.array<>>). It is however OK to use such type as type attribute operand in many FIR operation like fir.alloca, associated with SSA value for the dynamic extents, so we still need a conversion.

Since this type has no direct conversion to LLVM for the non constant extent case, it used to return the "most complete" representation as nested llvm.array, wrapped in a pointer type. And the fir.ptr type conversion would happily drop the pointer type from its converter fir.array base ([here](https://github.com/llvm/llvm-project/blob/ab76a7c56886821939981da68475ee2e6dd2467d/flang/include/flang/Optimizer/CodeGen/TypeConverter.h#L105C4-L109C37)).

This was a bit of a weird gymnastic because we were unhappy about fir.array<?xi32> being translated to i32. But this is not possible to do that anymore, now we need to propagate the "most complete" llvm value type representation directly.

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