[Debugify] Limit number of processed functions for original mode

Debugify in OriginalDebugInfo mode, does (DebugInfo) collect-before-pass & check-after-pass
for each instruction, which is pretty exp

[Debugify] Limit number of processed functions for original mode

Debugify in OriginalDebugInfo mode, does (DebugInfo) collect-before-pass & check-after-pass
for each instruction, which is pretty expensive. When used to analyze DebugInfo losses
in large projects (like LLVM), this raises the build time unacceptably.
This patch introduces a limit for the number of processed functions per compile unit.
By default, the limit is set to UINT_MAX (practically unlimited), and by using the introduced
option -debugify-func-limit the limit could be set to any positive integer number.

Differential revision: https://reviews.llvm.org/D115714

show more ...

Recommit: "[Debugify][Original DI] Test dbg var loc preservation""

[Debugify][Original DI] Test dbg var loc preservation

This is an improvement of [0]. This adds checking of
original ll

Recommit: "[Debugify][Original DI] Test dbg var loc preservation""

[Debugify][Original DI] Test dbg var loc preservation

This is an improvement of [0]. This adds checking of
original llvm.dbg.values()/declares() instructions in
optimizations.

We have picked a real issue that has been found with
this (actually, picked one variable location missing
from [1] and resolved the issue), and the result is
the fix for that -- D100844.

Before applying the D100844, using the options from [0]
(but with this patch applied) on the compilation of GDB 7.11,
the final HTML report for the debug-info issues can be found
at [1] (please scroll down, and look for
"Summary of Variable Location Bugs"). After applying
the D100844, the numbers has improved a bit -- please take
a look into [2].

[0] https://llvm.org/docs/HowToUpdateDebugInfo.html#\
test-original-debug-info-preservation-in-optimizations
[1] https://djolertrk.github.io/di-check-before-adce-fix/
[2] https://djolertrk.github.io/di-check-after-adce-fix/

Differential Revision: https://reviews.llvm.org/D100845

The Unit test was failing because the pass from the test that
modifies the IR, in its runOnFunction() didn't return 'true',
so the expensive-check configuration triggered an assertion.

show more ...

Revert "[Debugify][Original DI] Test dbg var loc preservation"

This reverts commit 76f375f3d9d6902820ffc21200e454926748c678.

This will be pushed again, after investigating a test failure:
https://l

Revert "[Debugify][Original DI] Test dbg var loc preservation"

This reverts commit 76f375f3d9d6902820ffc21200e454926748c678.

This will be pushed again, after investigating a test failure:
https://lab.llvm.org/buildbot/#/builders/16/builds/11254

show more ...

[Debugify][Original DI] Test dbg var loc preservation

This is an improvement of [0]. This adds checking of
original llvm.dbg.values()/declares() instructions in
optimizations.

We have picked a real

[Debugify][Original DI] Test dbg var loc preservation

This is an improvement of [0]. This adds checking of
original llvm.dbg.values()/declares() instructions in
optimizations.

We have picked a real issue that has been found with
this (actually, picked one variable location missing
from [1] and resolved the issue), and the result is
the fix for that -- D100844.

Before applying the D100844, using the options from [0]
(but with this patch applied) on the compilation of GDB 7.11,
the final HTML report for the debug-info issues can be found
at [1] (please scroll down, and look for
"Summary of Variable Location Bugs"). After applying
the D100844, the numbers has improved a bit -- please take
a look into [2].

[0] https://llvm.org/docs/HowToUpdateDebugInfo.html\
[1] https://djolertrk.github.io/di-check-before-adce-fix/
[2] https://djolertrk.github.io/di-check-after-adce-fix/

Differential Revision: https://reviews.llvm.org/D100845

show more ...

[Debugify] Expose original debug info preservation check as CC1 option

In order to test the preservation of the original Debug Info metadata
in your projects, a front end option could be very useful

[Debugify] Expose original debug info preservation check as CC1 option

In order to test the preservation of the original Debug Info metadata
in your projects, a front end option could be very useful, since users
usually report that a concrete entity (e.g. variable x, or function fn2())
is missing debug info. The [0] is an example of running the utility
on GDB Project.

This depends on: D82546 and D82545.

Differential Revision: https://reviews.llvm.org/D82547

show more ...

[Debugify][OriginalDIMode] Export the report into JSON file

By using the original-di check with debugify in the combination with
the llvm/utils/llvm-original-di-preservation.py it becomes very user

[Debugify][OriginalDIMode] Export the report into JSON file

By using the original-di check with debugify in the combination with
the llvm/utils/llvm-original-di-preservation.py it becomes very user
friendly tool. An example of the HTML page with the issues
related to debug info can be found at [0].

[0] https://djolertrk.github.io/di-checker-html-report-example/

Differential Revision: https://reviews.llvm.org/D82546

show more ...

Reland "[Debugify] Make the debugify aware of the original (-g) Debug Info"

As discussed on the RFC [0], I am sharing the set of patches that
enables checking of original Debug Info metadata

Reland "[Debugify] Make the debugify aware of the original (-g) Debug Info"

As discussed on the RFC [0], I am sharing the set of patches that
enables checking of original Debug Info metadata preservation in
optimizations. The proof-of-concept/proposal can be found at [1].

The implementation from the [1] was full of duplicated code,
so this set of patches tries to merge this approach into the existing
debugify utility.

For example, the utility pass in the original-debuginfo-check
mode could be invoked as follows:

$ opt -verify-debuginfo-preserve -pass-to-test sample.ll

Since this is very initial stage of the implementation,
there is a space for improvements such as:
- Add support for the new pass manager
- Add support for metadata other than DILocations and DISubprograms

[0] https://groups.google.com/forum/#!msg/llvm-dev/QOyF-38YPlE/G213uiuwCAAJ
[1] https://github.com/djolertrk/llvm-di-checker

Differential Revision: https://reviews.llvm.org/D82545

The test that was failing is now forced to use the old PM.

show more ...

Revert "[Debugify] Make the debugify aware of the original (-g) Debug Info"

This reverts rG8ee7c7e02953.
One test is failing, I'll reland this as soon as possible.

[Debugify] Make the debugify aware of the original (-g) Debug Info

As discussed on the RFC [0], I am sharing the set of patches that
enables checking of original Debug Info metadata preservation in

[Debugify] Make the debugify aware of the original (-g) Debug Info

As discussed on the RFC [0], I am sharing the set of patches that
enables checking of original Debug Info metadata preservation in
optimizations. The proof-of-concept/proposal can be found at [1].

The implementation from the [1] was full of duplicated code,
so this set of patches tries to merge this approach into the existing
debugify utility.

For example, the utility pass in the original-debuginfo-check
mode could be invoked as follows:

$ opt -verify-debuginfo-preserve -pass-to-test sample.ll

Since this is very initial stage of the implementation,
there is a space for improvements such as:
- Add support for the new pass manager
- Add support for metadata other than DILocations and DISubprograms

[0] https://groups.google.com/forum/#!msg/llvm-dev/QOyF-38YPlE/G213uiuwCAAJ
[1] https://github.com/djolertrk/llvm-di-checker

Differential Revision: https://reviews.llvm.org/D82545

show more ...

[SimplifyCFG] Keep !dgb metadata of moved instruction, if they match.

Currently SimplifyCFG drops the debug locations of 'bonus' instructions.
Such instructions are moved before the first branch. Th

[SimplifyCFG] Keep !dgb metadata of moved instruction, if they match.

Currently SimplifyCFG drops the debug locations of 'bonus' instructions.
Such instructions are moved before the first branch. The reason for the
current behavior is that this could lead to surprising debug stepping,
if the block that's folded is dead.

In case the first branch and the instructions to be folded have the same
debug location, this shouldn't be an issue and we can keep the debug
location.

Reviewed By: vsk

Differential Revision: https://reviews.llvm.org/D93662

show more ...

[Debugify] Support checking Machine IR debug info
Add mir-check-debug pass to check MIR-level debug info.

For IR-level, currently, LLVM have debugify + check-debugify to generate
and check debug IR.

[Debugify] Support checking Machine IR debug info
Add mir-check-debug pass to check MIR-level debug info.

For IR-level, currently, LLVM have debugify + check-debugify to generate
and check debug IR. Much like the IR-level pass debugify, mir-debugify
inserts sequentially increasing line locations to each MachineInstr in a
Module, But there is no equivalent MIR-level check-debugify pass, So now
we support it at "mir-check-debug".

Reviewed By: djtodoro

Differential Revision: https://reviews.llvm.org/D91595

show more ...

Revert "[Debugify] Support checking Machine IR debug info"

This reverts commit 50aaa8c274910d78d7bf6c929a34fe58b1f45579.

[Debugify] Support checking Machine IR debug info
Add mir-check-debug pass to check MIR-level debug info.

For IR-level, currently, LLVM have debugify + check-debugify to generate
and check debug IR.

[Debugify] Support checking Machine IR debug info
Add mir-check-debug pass to check MIR-level debug info.

For IR-level, currently, LLVM have debugify + check-debugify to generate
and check debug IR. Much like the IR-level pass debugify, mir-debugify
inserts sequentially increasing line locations to each MachineInstr in a
Module, But there is no equivalent MIR-level check-debugify pass, So now
we support it at "mir-check-debug".

Reviewed By: djtodoro

Differential Revision: https://reviews.llvm.org/D91595

show more ...

Revert "[Debugify] Support checking Machine IR debug info"

This reverts commit c4d2d4337d50bed3cafd564daece1a197005b22b.
Necessary to revert 2a5675f11d3bc803a245c0e.

[Debugify] Support checking Machine IR debug info
Add mir-check-debug pass to check MIR-level debug info.

For IR-level, currently, LLVM have debugify + check-debugify to generate
and check debug IR.

[Debugify] Support checking Machine IR debug info
Add mir-check-debug pass to check MIR-level debug info.

For IR-level, currently, LLVM have debugify + check-debugify to generate
and check debug IR. Much like the IR-level pass debugify, mir-debugify
inserts sequentially increasing line locations to each MachineInstr in a
Module, But there is no equivalent MIR-level check-debugify pass, So now
we support it at "mir-check-debug".

Reviewed By: djtodoro

Differential Revision: https://reviews.llvm.org/D91595

show more ...

Revert "[Debugify] Support checking Machine IR debug info"

This reverts commit 57a3d9ec4a8c1422f07264bed9f12a4ea416707e.

[Debugify] Support checking Machine IR debug info
Add mir-check-debug pass to check MIR-level debug info.

For IR-level, currently, LLVM have debugify + check-debugify to generate
and check debug IR.

[Debugify] Support checking Machine IR debug info
Add mir-check-debug pass to check MIR-level debug info.

For IR-level, currently, LLVM have debugify + check-debugify to generate
and check debug IR. Much like the IR-level pass debugify, mir-debugify
inserts sequentially increasing line locations to each MachineInstr in a
Module, But there is no equivalent MIR-level check-debugify pass, So now
we support it at "mir-check-debug".

Reviewed By: djtodoro

Differential Revision: https://reviews.llvm.org/D95195

show more ...

[docs] Recommend dropLocation() over setDebugLoc(DebugLoc())

[docs] Fix typo

[docs] Specify rules for updating debug locations

Summary:
Restructure HowToUpdateDebugInfo.rst to specify rules for when
transformations should preserve, merge, or drop debug locations.

The goal i

[docs] Specify rules for updating debug locations

Summary:
Restructure HowToUpdateDebugInfo.rst to specify rules for when
transformations should preserve, merge, or drop debug locations.

The goal is to have clear, well-justified rules that come with a few
examples and counter-examples, so that pass authors can pick the best
strategy for managing debug locations depending on the specific task at
hand.

I've tried to set down sensible rules here that mostly align with what
we already do in llvm today, and that take a diverse set of use cases
into account (interactive debugging, crash triage, SamplePGO).

Please *do* try to pick these rules apart and suggest clarifications or
improvements :).

Side note: Prior to 24660ea1, this document was structured as a long
list of very specific code transformations -- the idea being that we
would fill in what to do in each specific case. I chose to reorganize
the document as a list of actions to take because it drastically cuts
down on the amount of redundant exposition/explanation needed. I hope
that's fine...

Reviewers: jmorse, aprantl, dblaikie

Subscribers: llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D81198

show more ...

[docs] HowToUpdateDebugInfo: Minor cleanups

- Change the reference to salvageDebugInfoOrUndef to salvageDebugInfo
(in accordance with https://reviews.llvm.org/D78369).

- Reorganize a few sections

[docs] HowToUpdateDebugInfo: Minor cleanups

- Change the reference to salvageDebugInfoOrUndef to salvageDebugInfo
(in accordance with https://reviews.llvm.org/D78369).

- Reorganize a few sections in preparation for an upcoming change that
attempts to specify rules for updating debug locations.

- Fix some intra-document links.

- Some spelling / wording fixes.

show more ...

[docs] Sketch outline for HowToUpdateDebugInfo.rst

Summary:
Sketch the outline for a new document that explains how to update debug
info in various kinds of code transformations.

Some of the guidel

[docs] Sketch outline for HowToUpdateDebugInfo.rst

Summary:
Sketch the outline for a new document that explains how to update debug
info in various kinds of code transformations.

Some of the guidelines that belong in HowToUpdateDebugInfo.rst were in
SourceLevelDebugging.rst already under the debugify section. It seems
like the distinction between the two docs ought to be that the former is
more prescriptive, while the latter is more descriptive.

To that end I've consolidated the "how to update debug info" guidelines
which were in SourceLevelDebugging.rst into the new doc, along with the
information about using "debugify" to test transformations. Since we've
added a mir-debugify pass, I've described that as well.

Reviewers: aprantl, jmorse, chrisjackson, dsanders

Subscribers: llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D80052

show more ...