[flang][draft] Improve debug info generation.

[abidh]

This PR adds initial support for generation of debug information for variables and types. The aim is that it can be the basis of discussion on the design of debug information generation. It is complete enough to allow inspection of variables in GDB but will obviously need more work before it can be considered ready for inclusion.

This PR builds on the existing AddDebugFoundation pass. The existence of this pass and the DeclareOp seems to suggest that debug information was meant to be generated from HLFIR/FIR. However this approach presents some issues:

1. Some of the location information is difficult to extract from FIR. For example, the location where derived types and its members are declared in the source is not available (or atleast I could not figure out how to get them).

2. Things like fortran module is not a first class entity in IR. One can extract its name from the unique name of the type or variable but this is not ideal.

I have been wondering if it will be better to generate the debug information from AST where we have more complete information. Any ideas or suggestions on this are highly welcome.

Coming back to patch, it does the following:

1. Add bits in the Driver to allow full debug information and maps -g accordingly.
2. In AddDebugFoundationPass, add support to convert mlir::Type to DITypeAttr. The support is limited to scalars, fixed-size arrays and derived types for now.
3. Iterate GlobalOp to generate DIGlobalVariableAttr and attach it to the op.
4. Similarly attach DILocalVariableAttr to AllocaOp or LoadOp.
5. In Codegen, extract these attributes and generate the required MLIR metadata.

Then MLIR to llvm-ir does it work and we get the correct debug information in the executable. At the moment, module variables are being generated as global. DWARF does have the concept of the module that we can use but it is something for the future.

[kiranchandramohan]

Thanks for this patch to improve debug support in Flang. If you are planning to work long-time on enabling full debug support then it would be good to write a design document (in flang/docs), get it agreed upon by everyone and then proceed. I attempted some time ago at https://reviews.llvm.org/D138534. Could you go through the discussions there? You could adopt a similar style document. @jeanPerier @vzakhari and @tblah might have opinions.

There were some questions on how to generate debug info. This could be generated during lowering and carried in Ops. Alternatively, one of the motivations for adding hlfir.declare was to collect and retain variable information suitable for debug info generation. fir.declare also probably helps but it is probably dropped before we get to AddDebugFoundation.

The AddDebugFoundation pass was added to retain some location information generation that was lost due to some core MLIR changes. It is not compulsory to retain it if there are better ways to generate debug information.

[tblah]

Thank you for this patch! I like the approach so far using the existing debug pass.

My gut feeling is that I would rather this happen in a pass rather than earlier on (lowering or even semantics) because lowering is already too complicated and monolithic. In the past it has proven useful to break down complicated lowering steps into smaller pieces by self-contained passes (e.g. the transition from AST->FIR to AST->HLFIR->FIR). But I don't have any concrete examples - perhaps this won't be so difficult as I suspect, so I am open to other approaches.

1. Some of the location information is difficult to extract from FIR. For example, the location where derived types and its members are declared in the source is not available (or at least I could not figure out how to get them).
2. Things like fortran module is not a first class entity in IR. One can extract its name from the unique name of the type or variable but this is not ideal.

I would lean towards adding the information you need to (HL)FIR.

Location information is just a kind of attribute on an operation. I presume one could use additional location attributes to store the information you need in (HL)FIR. I'm not super familiar with derived types in FIR, but perhaps fir.type_info could be used/extended for this?

Similarly, perhaps the solution for a module would be to add a string attribute naming the module.

As Kiran said, it would be good to seek a wider discussion on this - either in review of a design document and/or in an RFC on https://discourse.llvm.org/c/subprojects/flang/33

[abidh]

Thanks @kiranchandramohan and @tblah for your comments. I do plan to work on this long term to bring the full debug support to flang. I will work on creating a design document.

[jeanPerier]

Great to see work on debug info, thanks!

I am in line with @tblah that we should aim at generating it from FIR/HLFIR as much as possible. For types, as Tom mentioned, fir.type_info could be updated to be created with the type declaration location if it is not already the case.

Variable names that are meant to be reversible (there are APIs to demangle), so it would seems reasonable to me to start by using this for to identify Module variables.

+1 for a design doc/RFC on the topic.