[flang][debug] Only and => operators are not respected for used modules.

[abidh]

Consider the following program.

module mod1
  integer var1
  integer var2
end module

module mod2
  integer var1
  integer var3
end module


PROGRAM  test
  use mod1, only: var2
	use mod2, var4 => var3
  !use mod3
  var1 = 10
  var4 = 20
  var2 = 30
  print *, var1
  print *, var2
  print *, var4
END PROGRAM test

When compiled and debugged in the GDB, here is what we get for var1 and var4 while stopped at first print line.

(gdb) p var1
Reference to "var1" is ambiguous, possibilities are: mod1::var1 and mod2::var1
(gdb) p var4
No symbol "var4" in current context.
(gdb) p var3
$1 = 20

The only and => were ignored by the debug information.

To fix this issue (and #160907), the information about module and the use statement have to be put in the FIR.

[llvmbot]

@llvm/issue-subscribers-debuginfo

Author: Abid Qadeer (abidh)

Consider the following program.

module mod1
  integer var1
  integer var2
end module

module mod2
  integer var1
  integer var3
end module


PROGRAM  test
  use mod1, only: var2
	use mod2, var4 => var3
  !use mod3
  var1 = 10
  var4 = 20
  var2 = 30
  print *, var1
  print *, var2
  print *, var4
END PROGRAM test

When compiled and debugged in the GDB, here is what we get for var1 and var4 while stopped at first print line.

(gdb) p var1
Reference to "var1" is ambiguous, possibilities are: mod1::var1 and mod2::var1
(gdb) p var4
No symbol "var4" in current context.
(gdb) p var3
$1 = 20

The only and => were ignored by the debug information.

To fix this issue (and #160907), the information about module and the use statement have to be put in the FIR.

[llvmbot]

@llvm/issue-subscribers-flang-ir

Author: Abid Qadeer (abidh)

Consider the following program.

module mod1
  integer var1
  integer var2
end module

module mod2
  integer var1
  integer var3
end module


PROGRAM  test
  use mod1, only: var2
	use mod2, var4 => var3
  !use mod3
  var1 = 10
  var4 = 20
  var2 = 30
  print *, var1
  print *, var2
  print *, var4
END PROGRAM test

When compiled and debugged in the GDB, here is what we get for var1 and var4 while stopped at first print line.

(gdb) p var1
Reference to "var1" is ambiguous, possibilities are: mod1::var1 and mod2::var1
(gdb) p var4
No symbol "var4" in current context.
(gdb) p var3
$1 = 20

The only and => were ignored by the debug information.

To fix this issue (and #160907), the information about module and the use statement have to be put in the FIR.

[jeanPerier]

@abidh, can you explain a bit how the ONLY should be handle at the DWARF/LLVM DI level?

From what I see in the current AddDebugInfo pass here, the code is looking for the DIModuleAttr for the Fortran module of a global symbol used inside a Function and the create a DIImportedEntityAttr, which as I understand it brings all DIModuleAttr symbols in the function scope.

Is there some DIImportedEntityAttr options to filter/only import selected names?

For the renaming, it would be easy to carry the local name on the fir.declare via a new attributes, but I am thinking that we need another way to carry info about use statements than using fir.declare to deal with ONLY, and also to avoid pruning unused fir.declare without removing the ability to generate debug info for accessible module variables.

The new representation will also have to work with BLOCK in the end to support debug info for:

module m
  integer :: i = 1
  integer :: j = 2
end module

subroutine test
  use m, only : i
  implicit none
  print *, i
  block
    use m, only : i => j
    print *, i
  end block
end subroutine

 call test
 end

The case of inlining at MLIR level is probably very similar to how BLOCK would be dealt with.

An attribute representation to describe Fortran scoping info like use statement looks like a reasonable solution to me here. I am still unclear if we should attach it to region operations like FuncOp (and some region based op for BLOCK, which I do not think we generate currently), or if we should bake it early in the location of the created operations (if that is even possible) to allow for easier IR motion without loosing scope information.

[abidh]

@abidh, can you explain a bit how the ONLY should be handle at the DWARF/LLVM DI level?

In flang, we import the whole module at once as shown below in the IR

!2 = !DIModule(name: "mod1")
!3 = !DIGlobalVariable(name: "var1", scope: !2)
!7 = DIGlobalVariable(name: "var2", scope: !2)

!11 = !DIModule(scope: !4, name: "mod2")
!12 = !DIGlobalVariable(name: "var1", scope: !11)
!13 = !DIGlobalVariable(name: "var3", scope: !11)

!17 = !DISubprogram(name: "TEST", retainedNodes: !21)
!21 = !{!22, !23}

!22 = !DIImportedEntity(tag: DW_TAG_imported_module, entity: !2)
!23 = !DIImportedEntity(tag: DW_TAG_imported_module, entity: !11)

For only, we could import just a single declaration as below. Or there could be multiple imports of such single declarations. As you can see in the last line, we could also give a name to the imported entity to implement renaming.

!11 = !DIModule(scope: !10, name: "mod1")
!13 = distinct !DIGlobalVariable(scope: !11, name: "var1")
!16 = distinct !DIGlobalVariable(scope: !11, name: "var2")

!19 = !DIModule(scope: !10, name: "mod2", file: !3, line: 6)
!20 = distinct !DIGlobalVariable(scope: !19, name: "var1")
!22 = distinct !DIGlobalVariable(scope: !19, name: "var3")

!27 = !{ !29, !30 }
!28 = distinct !DISubprogram(name: "test", retainedNodes: !27)
!29 = !DIImportedEntity(tag: DW_TAG_imported_declaration, entity: !16)
!30 = !DIImportedEntity(tag: DW_TAG_imported_declaration, entity: !22, name: "var4")

[abidh]

An attribute representation to describe Fortran scoping info like use statement looks like a reasonable solution to me here. I am still unclear if we should attach it to region operations like FuncOp (and some region based op for BLOCK, which I do not think we generate currently), or if we should bake it early in the location of the created operations (if that is even possible) to allow for easier IR motion without loosing scope information.

I see that currently that llvm.intr.stacksave and llvm.intr.stackrestore are generated at start and end of BLOCK construct. I guess those are similar markers could be used by AddDebugInfo to generated a DILexicalBlock. Then the variable inside them would have the correct scope. Although I think there may be some implicit assumptions in the code that local variables have function scope.