This is an archive of the discontinued LLVM Phabricator instance.

[Flang] Add debug flag to enable current debug information pass
ClosedPublic

Authored by SBallantyne on Mar 24 2023, 8:10 AM.

Details

Summary

While a pass exists to generate basic debug information, currently there is not a corresponding flag to enable it.
This patch adds support for activating this pass at any debug level >= -g1, as well as emiting a warning for higher levels that the functionality is not yet fully implemented.

This patch also adds -g and -gline-tables-only to appear when flang-new --help is run

Depends on D142347.

Diff Detail

Event Timeline

SBallantyne created this revision.Mar 24 2023, 8:10 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald Transcript
Herald added a subscriber: sunshaoce. · View Herald Transcript
SBallantyne requested review of this revision.Mar 24 2023, 8:10 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 24 2023, 8:10 AM
flang/include/flang/Frontend/CodeGenOptions.h
18

The following patch might be useful to avoid adding the clang header. Could you try it locally and see whether it works? If so you can either commandeer the following patch or alternatively include the following patch as part of the current one.
https://reviews.llvm.org/D142347

tblah added a comment.EditedMar 24 2023, 8:32 AM

Thanks for adding this flag.

Please could you add a test checking that the pass is actually run when the flag is given. For example, see the tests on this patch https://reviews.llvm.org/D146278

flang/include/flang/Tools/CLOptions.inc
22

nit: clang is conceptually "above" LLVM in the dependency hierarchy:

https://llvm.org/docs/CodingStandards.html#include-style

LLVM project and subproject headers should be grouped from most specific to least specific, for the same reasons described above. For example, LLDB depends on both clang and LLVM, and clang depends on LLVM. So an LLDB source file should include lldb headers first, followed by clang headers, followed by llvm headers, to reduce the possibility (for example) of an LLDB header accidentally picking up a missing include due to the previous inclusion of that header in the main source file or some earlier header file.

flang/lib/Frontend/FrontendActions.cpp
65

nit: is this include required?

Thanks for submitting this! Please add tests for -g and all variants of -gline-tables-only.

SBallantyne updated this revision to Diff 508165.EditedMar 24 2023, 11:03 AM

Add dependence on D142347 and update references to clang::codegenoptions to llvm::codegenoptions

Attempt 2 to add previous work as stacked patch

SBallantyne marked an inline comment as done.

Add test to check that debug pass is run and not run with appropriate flags

SBallantyne marked an inline comment as done.

Update tests to check for warning at higher debug levels, as well as amend warning message

What's the overall design goal here? 100% consistency with Clang? Could this be documented?

clang/include/clang/Driver/ToolChain.h
23 ↗(On Diff #508552)

Unrelated change?

clang/lib/Driver/ToolChains/Clang.h
16 ↗(On Diff #508552)

Unrelated change?

clang/lib/Driver/ToolChains/Flang.cpp
33
flang/lib/Frontend/CompilerInvocation.cpp
127
  1. Why unsigned instead of DebugInfoKind
  2. Why not use std::optional, e.g. llvm::StringSwitch<std::optional<DebugInfoKind>>arg->getValue())? This way you could avoid magic numbers like ~0U.
137

Please test this diagnostic. Also, if this is an error then you should return immediately and signal that this method has failed (e.g. return false;).

144

Please improve it :)

In particular, you are testing for DebugLineTablesOnly and NoDebugInfo, yet the diagnostic refers to -g1.

145

Looks like you are creating a warning rather than an error: debugErr --> debugWarn

SBallantyne marked 5 inline comments as done.

Add test for invalid debug-info-kind and address other review comments

What's the overall design goal here? 100% consistency with Clang? Could this be documented?

The goal of this patch is just to enable the current debug pass with an appropriate flag, and ensure that its fairly easy to expand this should more passes/work be done for flang. I've chosen to just copy the majority of the clang debug system on the assumption flang will follow the same path, but i don't think that is explicitly planned or the only way forwards.

clang/include/clang/Driver/ToolChain.h
23 ↗(On Diff #508552)

Accidental include from D142347, I've removed it there so it shouldn't have to be removed here.

flang/lib/Frontend/CompilerInvocation.cpp
127

Sure i'm happy to implement that here. This code originally comes from the clang frontend

144

I previously had it emit these debug names, but i think its more confusing for the user as they will be passing -g2 / -g3 in order to get this error, and the internal name is not as helpful. The TODO was from a previous patch and i just forgot to remove it, i am happy with the current state of warning.

Thanks for the updates! A few more pointers, but nothing major.

Btw, are there any tests that check for debug info in the compiled files? For example:

! RUN: flang -g1 -S %s | FileCheck -check-prefixes=DEBUG-INFO-PRESENT
! RUN: flang -g0 -S %s | FileCheck -check-prefixes=DEBUG-INFO-MISSING

end program
clang/lib/Driver/ToolChains/Flang.cpp
32

There isn't anything Fortran specific here, is there? And this method basically implements https://github.com/llvm/llvm-project/blob/cf60d3f1a688671c8eb7859bf0572c403c3c0cca/clang/lib/Driver/ToolChains/Clang.cpp#L975-L1000, right? Why not extract it into e.g. renderDebugEnablingArgs and move to CommonArgs.cpp?

flang/lib/Frontend/CompilerInvocation.cpp
144

Thanks for the explanation! My main reservation is that it's not obvious how -g2 and -g3 map onto llvm::codegenoptions. This warnings refers to -g1, but there's no mention of -g1 in this function.

TBH, I would replace "Debug options greater than -g1 not yet implemented" with something a bit more generic and future-proof, e.g. "Unsupported debug option: %0" << arg.getValue()

865–866

WDYT? I think that it makes sense to keep these separate.

SBallantyne marked an inline comment as done.

Add common function addDebugKindInfo, update warning message

awarzynski accepted this revision.Mar 28 2023, 4:12 AM

LGTM, thanks for working on this! (please fix the name in CommonArgs.h before landing this)

It would be great to see a test that checks for debug info in the generated FIR/MLIR/LLVM-IR/ASM file. But that could happen in a separate patch.

clang/lib/Driver/ToolChains/CommonArgs.h
111

CamelCase or camelCase? ;-)

This revision is now accepted and ready to land.Mar 28 2023, 4:12 AM
SBallantyne marked an inline comment as done.

Fix case issue. As for tests for debug information being generated, these are already covered by various tests in flang/tests/Transforms, namely debug-line-table.fir, debug-line-table-existing.fir etc.
While the tests are invoked through fir-opt instead of a flang flag, it is the same pass that is verified to be run in the tests added so is covered.

Thanks for the explanation! Still looking good apart from the function names ;)

clang/lib/Driver/ToolChains/CommonArgs.h
111

Sorry, I meant that this function uses wrong casing. It ought to be debugLevelToInfoKind and addDebugInfoKind: https://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly

clang/lib/Driver/ToolChains/CommonArgs.h
111

I thought that the general rule was that the style guide should be followed apart from when there is already code in a particular style in a file, however i have realised that while most functions in this file are CamelCase, there are some that are camelCase, so i am unsure of what is the right way.

awarzynski added inline comments.Mar 28 2023, 8:15 AM
clang/lib/Driver/ToolChains/CommonArgs.h
111

Yes, it's very confusing :(

You are right about the official guidelines (at least that's how I understand them). In this case the style used in this file is inconsistent so you can't follow that (i.e. because there are multiple styles used here). In situations like this I would follow the official style guideline instead.

Update style to mach style guidelines

clang/lib/Driver/ToolChains/CommonArgs.h
111

Sounds reasonable, I've changed it to follow style guideline instead.

Clang format

This revision was landed with ongoing or failed builds.Mar 29 2023, 5:21 AM
This revision was automatically updated to reflect the committed changes.