[Mlir-commits] [mlir] [mlir][flang] Improve handling of fortran module variables. (PR #91604)

[Abid Qadeer]

abidh wrote:

> Can you elaborate on why the variable's scope is not already set accordingly by flang? I assume that there is some reason for this, but I'm not familiar enough with flang to know this detail.

Global variable in the context of DWARF is a bit of a loaded term. Same constructs that are used for C/C++ global variables are also used for module variables in Fortran (and namespace variables in C++). MLIR code is assuming that global variable will always have compile unit scope which may not be correct in those cases.

Take the example of namespace in c++ below. The debug metadata was generated by `clang`. You can see that scope of the global variable `a` is set to namespace (and not to compile unit) but it still gets added to `globals` in `DICompileUnit`. 

```
namespace test
{
    int a;
}

!0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
!1 = distinct !DIGlobalVariable(name: "a", linkageName: "_ZN4test1aE", scope: !2 ...)
!2 = !DINamespace(name: "test", scope: null)
!5 = distinct !DICompileUnit(... globals: !6 ...)
!6 = !{!0}
```

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.

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