Closed vzakhari closed 1 year ago
@llvm/issue-subscribers-flang-ir
OR, should func.func to llvm.func converter automatically create FusedLoc with DI metadata, if there is none attached?
I wouldn't expect the converter to implicitly add metadata if it wasn't there. Part of this effort to actually setup debug info to work the way it's expected, i.e. we should no longer be implicitly adding metadata (at least in the general infra, specific projects can of course do what works best for them).
I suppose the expectation is that the MLIR producer (e.g. Flang front-end) establishes proper FusedLoc for the generated func.func's, which are then propagated to llvm.func during conversion to LLVM dialect.
Yeah, that's the intention of this effort; to enable frontends to specify debug information and have it correctly propagated/exported to LLVM. It means losing the implicity, but you gain the ability to specify real debug info (instead of the fake stuff we generated before).
Thank you for clarification, River!
I have a WIP patch for this https://reviews.llvm.org/D137956.
This patch adds a pass that provides some foundation work with which
basic line table debug info can be generated. A walk is performed on
all the func ops in the module and they are decorated with a fusedLoc
op that contains the debug metadata for the subroutine along with
location information.
Alternatives ways include populating this info during lowering or during FIR
to LLVM Dialect conversion.
After https://reviews.llvm.org/D136543 Flang is not producing debug line table for compiled Fortran programs. Even though the new code can translate MLIR Locaction's into debug line entries, it bails out for functions (llvm.func) that do not provide FusedLoc with the metadata holding DIScopeAttr.
I suppose the expectation is that the MLIR producer (e.g. Flang front-end) establishes proper FusedLoc for the generated func.func's, which are then propagated to llvm.func during conversion to LLVM dialect.
FYI, @River707