[flang-commits] [PATCH] D136254: [flang] add fir.declare codegen support

[Jean Perier via Phabricator via flang-commits]

jeanPerier added a comment.

In D136254#3869772 <https://reviews.llvm.org/D136254#3869772>, @kiranchandramohan wrote:

> In D136254#3868706 <https://reviews.llvm.org/D136254#3868706>, @jeanPerier wrote:
>
>> In D136254#3868201 <https://reviews.llvm.org/D136254#3868201>, @kiranchandramohan wrote:
>>
>>> Are the pre-codegen ops enough for carrying the debug info to LLVM dialect? Or would we require lowering the `fir.declare` op to LLVM at some point when we add debug info? Would an alternative path be for `fir.declare` to subsume the precodegen dialect ops?
>>
>> I think it will likely need to go a bit further, but since I do not know how debug info will look like in LLVM IR dialect, I cannot be assertive and I do not want to add a cg fir.declare at that stage just in case. It should really not be hard to add when the need arise, or to even allow fir.shape to be translated to some llvm tuple value in codegen and keep fir.declare until then. It may also actually turnout to be possible to already generate debug info in precodegen, this really depends on what should be generated.
>>
>> I would be really happy if an LLVM debug info expert could jump in on the debug info task and set the exact requirement and plan for FIR/LLVM dialect here.
>
> It has been a few years since I worked on Debug Metadata. For a simple adjustable array like `marr` in the following example
>
>   subroutine sb(marr, n)
>     integer :: n
>     integer :: marr(n)
>   end subroutine
>
> the debug generated in LLVM IR has to be something like the following. There is a debug declare for the array `marr`. The metadata attached to `marr` will be of kind `DILocalVariable` whose `type` will list it as an `array `and the `elements` field of the type will point to a range (`DISubrange`) with fields `lowerBound` and `upperBound`. In this case the `lowerBound` will be 1 and the upperbound will be another variable that has the value loaded from `n`.
>
>   define void @sb_(i64* %marr, i64* %n) #0 {
>   ...
>   call void @llvm.dbg.declare(metadata i64* %marr, metadata !15, metadata !DIExpression()),
>   ...
>   }
>   
>   !8 = !DICompositeType(tag: DW_TAG_array_type, baseType: !9, size: 32, align: 32, elements: !10)
>   !9 = !DIBasicType(name: "integer", size: 32, align: 32, encoding: DW_ATE_signed)
>   !10 = !{!11}
>   !11 = !DISubrange(lowerBound: 1, upperBound: !12)
>   !12 = distinct !DILocalVariable(name: "z_e_13", scope: !5, file: !3, type: !13, flags: DIFlagArtificial)
>   !15 = !DILocalVariable(name: "marr", arg: 1, scope: !5, file: !3, line: 1, type: !8)

Thanks @kiranchandramohan for the illustration. Currently, is there a way to generate DIExpression metadata and llvm.dbg calls in the LLVM MLIR dialect ? I found this file in MLIR [1], but I am not sure it can generate a lot on top of location information. If not, before we can do anything in FIR about this, something will have to be added (extending LLVM dialect or maybe even adding a DIExpression dialect in MLIR).

[1] https://github.com/llvm/llvm-project/blob/main/mlir/lib/Target/LLVMIR/DebugTranslation.h


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136254/new/

https://reviews.llvm.org/D136254