[Mlir-commits] [mlir] [mlir][flang] Improve handling of fortran module variables. (PR #91604)
Christian Ulmann
llvmlistbot at llvm.org
Fri May 10 08:37:34 PDT 2024
Dinistro wrote:
> > > Fortran module variables are also represented as global variable in DWARF. But to recognize that they are part of a module, their scope is set to module and not to compile unit. In summary, the scope of the variable is correct. The MLIR check is overly restrictive and this PR amends it for this specific case.
> >
> >
> > Thanks for the clarification. Ideally, we would model `DICompile` units to also have a `globals` field, but this would result in circular attribute structures. While supporting such constructs is possible, it's quite involved to get this to work and is tricky to work with.
>
> `DICompileUnit` does have a globals field. Although it is not exposed through DIBuilder::createCompileUnit. Generally, when `DICompileUnit` is created, you don't have the list of globals. The `DICompileUnit` has `replaceGlobalVariables` to set the list of globals once they have been processed, providing a way to break circular dependency.
I was referring to the MLIR attribute that is supposed to be isomorphic to the LLVM representation. Modeling the equivalent in MLIR's LLVM dialect would be much more complicate due to limits of the attribute subsystem.
Either way, if this is how it's supposed to be modelled, I'm fine with this change 😄
https://github.com/llvm/llvm-project/pull/91604
More information about the Mlir-commits
mailing list