[flang][debug] Add support for common blocks. (#112398)

This PR adds debug support for common block in flang. As variable which
are part of a common block don't have a special marker to recognize

[flang][debug] Add support for common blocks. (#112398)

This PR adds debug support for common block in flang. As variable which
are part of a common block don't have a special marker to recognize
them, we use the following check to find them.

%0 = fir.address_of(@a)
%1 = fir.convert %0
%2 = fir.coordinate_of %1, %c0
%3 = fir.convert %2
%4 = fircg.ext_declare %3

If the memref of a fircg.ext_declare points to a fir.coordinate_of and
that in turn points to an fir.address_of (ignoring immediate
fir.convert) then we assume that it is a common block variable. The
fir.address_of gives us the global symbol which is the storage for
common block and fir.coordinate_of provides the offset in this storage.

The debug hierarchy looks like as

subroutine f3
integer :: x, y
common /a/ x, y
end subroutine

@a_ = global { ... } { ... }, !dbg !26, !dbg !28

!23 = !DISubprogram(name: "f3"...)
!24 = !DICommonBlock(scope: !23, name: "a", ...)
!25 = !DIGlobalVariable(name: "x", scope: !24 ...)
!26 = !DIGlobalVariableExpression(var: !25, expr: !DIExpression())
!27 = !DIGlobalVariable(name: "y", scope: !24 ...)
!28 = !DIGlobalVariableExpression(var: !27, expr:
!DIExpression(DW_OP_plus_uconst, 4))

This required following changes:

1. Instead of using DIGlobalVariableAttr in the FusedLoc of GlobalOp, we
use DIGlobalVariableExpressionAttr. This allows us the generate the
DIExpression where we have the information.

2. Previously, only one DIGlobalVariableExpressionAttr could be linked
to one global op. I recently removed this restriction in mlir. To make
use of it, we add an ArrayAttr to the FusedLoc of a GlobalOp. This
allows us to pass multiple DIGlobalVariableExpressionAttr.

3. I was depending on the name of global for the name of the common
block. The name gets a '_' appended. I could not find a utility function
in flang to remove it so I have to brute force it.

show more ...

[flang][debug] Fix issue with argument numbering. (#120726)

Currently fir::isDummyArgument is being used to check if a DeclareOp
represents a dummy argument. The argument passed to the function is

[flang][debug] Fix issue with argument numbering. (#120726)

Currently fir::isDummyArgument is being used to check if a DeclareOp
represents a dummy argument. The argument passed to the function is
declOp.getMemref(). This bypasses the code in isDummyArgument that
checks for dummy_scope because the `Value` returned by the getMemref()
may not have DeclareOp as its defining op.

This bypassing mean that sometime a variable will be marked as argument
when it should not. This happened in this case where same arg was being
used for 2 different result variables with use of `entry` in the
function.

The solution is to check directly if the declOp has a dummy_scope. If
yes, we know this is dummy argument. We can now check if the memref
points to the BlockArgument and use its number. This will still miss
arguments where memref does not directly point to a BlockArgument but
that is missed currently too. Note that we can still evaluate those
variable in debugger. It is just that they are not marked as arguments.

Fixes #116525.

show more ...

[flang][debug] Don't generate debug for compiler-generated variables (#112423)

Flang generates many globals to handle derived types. There was a check
in debug info to filter them based on the info

[flang][debug] Don't generate debug for compiler-generated variables (#112423)

Flang generates many globals to handle derived types. There was a check
in debug info to filter them based on the information that their names
start with a period. This changed since PR#104859 where 'X' is being
used instead of '.'.

This PR fixes this issue by also adding 'X' in that list. As user
variables gets lower cased by the NameUniquer, there is no risk that
those will be filtered out. I added a test for that to be sure.

show more ...

[mlir][debuginfo] Add support for subprogram annotations (#110946)

LLVM already supports `DW_TAG_LLVM_annotation` entries for subprograms,
but this hasn't been surfaced to the LLVM dialect.
I'm do

[mlir][debuginfo] Add support for subprogram annotations (#110946)

LLVM already supports `DW_TAG_LLVM_annotation` entries for subprograms,
but this hasn't been surfaced to the LLVM dialect.
I'm doing the minimal amount of work to support string-based
annotations, which is useful for attaching metadata to
functions, which is useful for debuggers to offer features beyond basic
DWARF.
As LLVM already supports this, this patch is not controversial.

show more ...

[flang][debug] set DW_AT_main_subprogram for fortran main function (#111350)

Requested here
https://github.com/llvm/llvm-project/pull/111022#issuecomment-2396287781

[flang][debug] Use PROGRAM name for main function name (#111022)

For example, in

PROGRAM test_program
...
END PROGRAM

This allows a user to break on the main functi

[flang][debug] Use PROGRAM name for main function name (#111022)

For example, in

PROGRAM test_program
...
END PROGRAM

This allows a user to break on the main function with `break
test_program`. This matches what classic flang and gfortran do.

show more ...

[flang][debug] Generate correct subroutine type. (#108605)

We pass a list of types when creating a subroutine type. The first one
is supposed to be return type and the rest are the argument types.

[flang][debug] Generate correct subroutine type. (#108605)

We pass a list of types when creating a subroutine type. The first one
is supposed to be return type and the rest are the argument types. A
subroutine does not have a return type so an argument type could be
confused as a return type. To fix this, if there is no return type, we
generate a null type as a place holder.

Fixes #108564.

show more ...

[flang][debug] Handle 'used' module. (#107626)

As described in #98883, we have to qualify a module variable name in
debugger to get its value. This PR tries to remove this limitation.

LLVM p

[flang][debug] Handle 'used' module. (#107626)

As described in #98883, we have to qualify a module variable name in
debugger to get its value. This PR tries to remove this limitation.

LLVM provides `DIImportedEntity` to handle such cases but the PR is made
more complicated due to the following 2 issues.

1. The MLIR attributes are readonly and we have a circular dependency
here. This has to be handled using the recursive interface provided by
the MLIR. This requires us to first create a place holder
`DISubprogramAttr` which is used in creating `DIImportedEntityAttr`.
Later another `DISubprogramAttr` is created which replaces the place
holder.

2. The flang IR does not provide any information about the 'used' module
so this has to be extracted by doing a pass over the
`DeclareOp` in the function. This presents certain limitation as 'only'
and module variable renaming may not be handled properly.

Due to the change in `DISubprogramAttr`, some tests also needed to be
adjusted.

Fixes #98883.

show more ...

[OpenMPIRBuilder] Don't drop debug info for target region. (#80692)

When an outlined function is generated for omp target region, a
corresponding DISubprogram was not being generated. This resulted

[OpenMPIRBuilder] Don't drop debug info for target region. (#80692)

When an outlined function is generated for omp target region, a
corresponding DISubprogram was not being generated. This resulted in all
the debug information for the target region being dropped.

This commit adds DISubprogram for the outlined function if there is one
available for the parent function. It also updates the current debug
location so that the right scope is used for the entries in the outlined
function.

There are places in the OpenMPIRBuilder which changes insertion point but
don't update the debug location accordingly. They cause issue when debug info
is enabled. I have fixed a few that I observed to cause issue. But there may be
more and a systematic cleanup may be required.

With this change in place, I can set source line breakpoint in target
region and run to them in debugger.

show more ...

[mlir][debug] Handle DIImportedEntity. (#103055)

The `DIImporedEntity` can be used to represent imported entities like
C++'s namespace with using directive or fortran's moudule with use
statement.

[mlir][debug] Handle DIImportedEntity. (#103055)

The `DIImporedEntity` can be used to represent imported entities like
C++'s namespace with using directive or fortran's moudule with use
statement.

This PR adds `DIImportedEntityAttr` and 2-way translation from
`DIImportedEntity` to `DIImportedEntityAttr` and vice versa.

When an entity is imported in a function, the `retainedNodes` field of
the `DISubprogram` contains all the imported nodes. See the C++ code and
the LLVM IR below.

```
void test() {
using namespace n1;
...
}

!2 = !DINamespace(name: "n1", scope: null)
!16 = distinct !DISubprogram(name: "test", ..., retainedNodes: !19) !19 = !{!20}
!20 = !DIImportedEntity(tag: DW_TAG_imported_module, scope: !16, entity: !2 ...)
```

This PR makes sure that the translation from mlir to `retainedNodes`
field happens correctly both ways.

To side step the cyclic dependency between `DISubprogramAttr` and `DIImportedEntityAttr`,
we have decided to not have `scope` field in the `DIImportedEntityAttr` and it is inferred
from the entity which hold the list of `DIImportedEntityAttr`. A `retainedNodes` field has been
added in the `DISubprogramAttr` which contains the list of `DIImportedEntityAttr` for that
function.

This PR currently does not handle entities imported in a global scope
but that should be easy to handle in a subsequent PR.

show more ...

[flang][debug] Support derived types. (#99476)

This PR adds initial debug support for derived type. It handles
`RecordType` and generates appropriate `DICompositeTypeAttr`. The
`TypeInfoOp` is use

[flang][debug] Support derived types. (#99476)

This PR adds initial debug support for derived type. It handles
`RecordType` and generates appropriate `DICompositeTypeAttr`. The
`TypeInfoOp` is used to get information about the parent and location of
the derived type.

We use `getTypeSizeAndAlignment` to get the size and alignment of the
components of the derived types. This function needed a few changes to
be suitable to be used here:

1. The `getTypeSizeAndAlignment` errored out on unsupported type which
would not work with incremental way we are building debug support. A new
variant of this function has been that returns an std::optional. The original
function has been renamed to `getTypeSizeAndAlignmentOrCrash` as it
will call `TODO()` for unsupported types.

2. The Character type was returning size of just element and not the
whole string which has been fixed.

The testcase checks for offsets of the components which had to be
hardcoded in the test. So the testcase is currently enabled on x86_64.

With this PR in place, this is how the debugging of derived types look
like:

```
type :: t_date
integer :: year, month, day
end type

type :: t_address
integer :: house_number
end type
type, extends(t_address) :: t_person
character(len=20) name
end type
type, extends(t_person) :: t_employee
type(t_date) :: hired_date
real :: monthly_salary
end type
type(t_employee) :: employee

(gdb) p employee
$1 = ( t_person = ( t_address = ( house_number = 1 ), name = 'John', ' ' <repeats 16 times> ), hired_date = ( year = 2020, month = 1, day = 20 ), monthly_salary = 3.1400001 )
```

show more ...

[flang][debug] Allow non default array lower bounds. (#104467)

As mentioned in #98877, we currently always use 1 as lower bound for
fixed size arrays. This PR removes this restriction. It passes al

[flang][debug] Allow non default array lower bounds. (#104467)

As mentioned in #98877, we currently always use 1 as lower bound for
fixed size arrays. This PR removes this restriction. It passes along
`DeclareOp` to type conversion functions and uses the shift information
(if present) to get the lower bound value. This was suggested by
@jeanPerier in
https://github.com/llvm/llvm-project/pull/96746#issuecomment-2195164553

This PR also adds a small cleanup that type conversion functions don't
take Location now. It was initially added so that location of derived
types can be passed. But that information can be extracted from typeInfo
objects and we don't need to pass it along.

This PR will handle the problem for local and global variable. We may
need a bit more work for derived type once the support for derived types
lands.

Fixes #98877.

show more ...

[flang][debug] Set scope of internal functions correctly. (#99531)

The functions internal to subroutine should have the scope set to the
parent function. This allows a user to evaluate local variab

[flang][debug] Set scope of internal functions correctly. (#99531)

The functions internal to subroutine should have the scope set to the
parent function. This allows a user to evaluate local variables of
parent function when control is stopped in the child.

Fixes #96314

show more ...

[MLIR][DebugInfo] Enable the use of DILocalVariable DIFlags (#100190)

This patch enables the use of flags for local variables in debug info.
They were defaulted as always zero, but allowing them is

[MLIR][DebugInfo] Enable the use of DILocalVariable DIFlags (#100190)

This patch enables the use of flags for local variables in debug info.
They were defaulted as always zero, but allowing them is pretty trivial.

show more ...

[flang] Enhance location information (#95862)

Add inclusion location information by using FusedLocation with
attribute.

More context here:
https://discourse.llvm.org/t/rfc-enhancing-location-in

[flang] Enhance location information (#95862)

Add inclusion location information by using FusedLocation with
attribute.

More context here:
https://discourse.llvm.org/t/rfc-enhancing-location-information/79650

show more ...

[flang][debug] Generate correct name for external function. (#99510)

The `ExternalNameConversion` will add an _ at the end of the external
functions. We extract the real function name to use in the

[flang][debug] Generate correct name for external function. (#99510)

The `ExternalNameConversion` will add an _ at the end of the external
functions. We extract the real function name to use in the debug info.
The convention is to use the real name of function in the `name` field
and mangled name with extra _ at the end in the `linkageName` field.

Fixes #92391.

show more ...

[flang][debug] Fix issues with local variables. (#98661)

This PR fixes 2 similar issues.
1. As reported in #97476, flang generated executable has inconsistent
behavior regarding values of the loca

[flang][debug] Fix issues with local variables. (#98661)

This PR fixes 2 similar issues.
1. As reported in #97476, flang generated executable has inconsistent
behavior regarding values of the local array variables.
2. Variable with save attribute would not show up in debugger.

The reason behind is same for both cases. If a local variable has
storage which extends beyond function lifetime, the way to represent it
in the debug info is through a global variable whose scope is limited to
the function. This is what is used for static local variable in C.
Previously local array worked in cases they were on stack. But will not
show up if they had a global storage.

To fix this, if we can get a corresponding `GlobalOp` for a variable
while processing `DeclareOp`, we treat it the variable as global with
scope set appropriately. A new FIR test is added. A previous Integration
test has been adjusted as to not expect local variables for local
arrays.

With this fix in place, all the issues described in #97476 go away. It
also fixes a lot of fails in GDB's fortran testsuite.

Fixes #97476.

show more ...

[flang] Use fir.declare/fir.dummy_scope for TBAA tags attachments. (#92472)

With MLIR inlining (e.g. `flang-new -mmlir -inline-all=true`)
the current TBAA tags attachment is suboptimal, because
we

[flang] Use fir.declare/fir.dummy_scope for TBAA tags attachments. (#92472)

With MLIR inlining (e.g. `flang-new -mmlir -inline-all=true`)
the current TBAA tags attachment is suboptimal, because
we may lose information about the callee's dummy arguments
(by bypassing fir.declare in AliasAnalysis::getSource).
This is a conservative first step to improve the situation.
This patch makes AddAliasTagsPass to account for fir.dummy_scope
hierarchy after MLIR inlining and use it to place the TBAA tags
into TBAA trees corresponding to different function scopes.
The pass uses special mode of AliasAnalysis to find the instantiation
point of a Fortran variable (a [hl]fir.decalre) when searching
for the source of a memory reference. In this mode, AliasAnalysis
will always stop at fir.declare operations that have dummy_scope
operands - there should not be a reason to past throught it
for the purpose of TBAA tags attachment.

show more ...

[flang] Emit `argNo` debug info only for `func` block args (#93921)

Fixes a bug uncovered by
[pr43337.f90](https://github.com/llvm/llvm-test-suite/blob/main/Fortran/gfortran/regression/gomp/pr43337

[flang] Emit `argNo` debug info only for `func` block args (#93921)

Fixes a bug uncovered by
[pr43337.f90](https://github.com/llvm/llvm-test-suite/blob/main/Fortran/gfortran/regression/gomp/pr43337.f90)
in the test suite.

In particular, this emits `argNo` debug info only if the parent op of a
block is a `func.func` op. This avoids DI conflicts when a function
contains a nested OpenMP region that itself has block arguments with DI
attached to them; for example, `omp.parallel` with delayed privatization
enabled.

show more ...

[flang] Add debug information for module variables. (#91582)

This PR add debug info for module variables. The module variables are
added as global variables but their scope is set to module instead

[flang] Add debug information for module variables. (#91582)

This PR add debug info for module variables. The module variables are
added as global variables but their scope is set to module instead of
compile unit. The scope of function declared inside a module is also set
accordingly.

After this patch, a module variable could be evaluated in the GDB as `p
helper::gli` where helper is name of the module and gli is the name of
the variable. A future patch will add the import module functionality
which will remove the need to prefix the name with helper::.

The line number where is module is declared is a best guess at the
moment as this information is not part of the GlobalOp.

show more ...

[reland][flang] Initial debug info support for local variables (#92304)

This is same as #90905 with an added fix. The issue was that we
generated variable info even when user asked for line-tables-

[reland][flang] Initial debug info support for local variables (#92304)

This is same as #90905 with an added fix. The issue was that we
generated variable info even when user asked for line-tables-only. This
caused llvm dwarf generation code to fail an assertion as it expected an
empty variable list.

Fixed by not generating debug info for variables when user wants only
line table. I also updated a test check for this case.

show more ...

Revert "[flang] Initial debug info support for local variables. (#909… (#92302)

…05)"

This reverts commit 61da6366d043792d7db280ce9edd2db62516e0e8.

Update #90905 was causing many tests to fail

Revert "[flang] Initial debug info support for local variables. (#909… (#92302)

…05)"

This reverts commit 61da6366d043792d7db280ce9edd2db62516e0e8.

Update #90905 was causing many tests to fail.

See comments in #90905.

show more ...

[flang] Initial debug info support for local variables. (#90905)

We need the information in the `DeclareOp` to generate debug information
for variables. Currently, cg-rewrite removes the `DeclareO

[flang] Initial debug info support for local variables. (#90905)

We need the information in the `DeclareOp` to generate debug information
for variables. Currently, cg-rewrite removes the `DeclareOp`. As
`AddDebugInfo` runs after that, it cannot process the `DeclareOp`. My
initial plan was to make the `AddDebugInfo` pass run before the cg-rewrite
but that has few issues.

1. Initially I was thinking to use the memref op to carry the variable
attr. But as @tblah suggested in the #86939, it makes more sense to
carry that information on `DeclareOp`. It also makes it easy to handle
it in codegen and there is no special handling needed for arguments. For
this reason, we need to preserve the `DeclareOp` till the codegen.

2. Running earlier, we will miss the changes in passes that run between
cg-rewrite and codegen.

But not removing the DeclareOp in cg-rewrite has the issue that ShapeOp
remains and it causes errors during codegen. To solve this problem, I
convert DeclareOp to XDeclareOp in cg-rewrite instead of removing
it. This was mentioned as possible solution by @jeanPerier in
https://reviews.llvm.org/D136254

The conversion follows similar logic as used for other operators in that
file. The FortranAttr and CudaAttr are currently not converted but left
as TODO when the need arise.

Now `AddDebugInfo` pass can extracts information about local variables
from `XDeclareOp` and creates `DILocalVariableAttr`. These are attached
to `XDeclareOp` using `FusedLoc` approach. Codegen can use them to
create `DbgDeclareOp`. I have added tests that checks the debug
information in mlir from and also in llvm ir.

Currently we only handle very limited types. Rest are given a place
holder type. The previous placeholder type was basic type with
`DW_ATE_address` encoding. When variables are added, it started
causing assertions in the llvm debug info generation logic for some
types. It has been changed to an interger type to prevent these issues
until we handle those types properly.

show more ...

[flang] Update calls to isa/dyn_cast/dyn_cast_or_null

Reapply "[flang] Improve debug info for functions." with regression fixed. (#90484)

The original PR #90083 had to be reverted in PR #90444 as it caused one
of the gfortran tests to fail. The issue

Reapply "[flang] Improve debug info for functions." with regression fixed. (#90484)

The original PR #90083 had to be reverted in PR #90444 as it caused one
of the gfortran tests to fail. The issue was using `isIntOrIndex` for
checking for integer type. It allowed index type which later caused
assertion when calling `getIntOrFloatBitWidth`. I have now replaced it
with `isInteger` which should fix this regression.

show more ...