LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 37728 - [meta] Make llvm passes debug info invariant
Summary: [meta] Make llvm passes debug info invariant
Status: NEW
Alias: None
Product: new-bugs
Classification: Unclassified
Component: new bugs (show other bugs)
Version: unspecified
Hardware: PC All
: P enhancement
Assignee: Unassigned LLVM Bugs
URL:
Keywords:
: 43757 (view as bug list)
Depends on: 37240 37715 37727 40969 41111 43859 44422 44880 49691 49700 51110 51181 51195 51196 51569 51570 52538 52539 52540 37306 37713 37714 37726 42138 43291 43758 43964 49446 49982 50580
Blocks:
  Show dependency tree
 
Reported: 2018-06-07 00:52 PDT by Vedant Kumar
Modified: 2021-11-17 19:47 PST (History)
17 users (show)

See Also:
Fixed By Commit(s):


Attachments
check_cfc test script (3.81 KB, application/x-shellscript)
2019-10-24 18:22 PDT, Chris Ye
Details
check_cfc test result (24.81 KB, text/x-log)
2019-10-24 18:27 PDT, Chris Ye
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Vedant Kumar 2018-06-07 00:52:58 PDT
This is a meta bug for tracking work related to making llvm passes debug info invariant. That means that the output of llvm passes should be the same, modulo debug info metadata & intrinsics, regardless of whether the input IR contains debug info. The motivation for this is that enabling debug info should not degrade optimizations.

There are at least two different approaches for detecting debug invariance bugs:

1. Compile a C program with/without -g, and check that the resulting text sections are identical.

2. Compile some LLVM IR using opt, with/without -debugify-each enabled, and check that the stripped output is identical. The -debugify-each mode applies/removes synthetic debug info to a Module before/after each pass in opt's pipeline.

The second approach might be a bit more flexible, seeing as it's possible to generate LLVM IR from a C program, and to then run a custom pipeline over the IR using opt.

In addition to finding debug invariance bugs, we should think about setting up infrastructure to detect regressions, and about adding utilities to the codebase which might make it easier to write debug info invariant passes.
Comment 1 Greg Bedwell 2018-06-07 06:00:19 PDT
(In reply to Vedant Kumar from comment #0)
> 1. Compile a C program with/without -g, and check that the resulting text
> sections are identical.
> 

For this approach we have:
https://llvm.org/devmtg/2015-04/slides/Verifying_code_gen_dash_g_final.pdf

We have this pipeline setup for some our Sony internal test-suites and it's generally very effective FWIW.  We've not had the spare bandwidth to fix all of the existing bugs unfortunately, but we do tend to report/fix regressions as we spot them.  Hopefully we'll be able to find some spare bandwidth to help with this effort :)
Comment 2 Paul Robinson 2018-06-07 06:20:36 PDT
Added a couple older bugs to the list.  Post-RA Scheduler will likely be
pretty unpleasant, but it clearly has an effect and showed up fairly
often in our dash-g-no-change pipeline.
Comment 3 Chris Ye 2019-10-24 18:22:37 PDT
Created attachment 22723 [details]
check_cfc test script

This is a shell script tool calling check_cfc.py to detect codegen difference with/without -g

Run as: ./check_cfc.sh 2>test_err.log
Comment 4 Chris Ye 2019-10-24 18:27:25 PDT
Created attachment 22724 [details]
check_cfc test result

After run check_cfc.sh with llvm_test_suite as test code,
Codegen differences found in test_err.log
Comment 5 Chris Ye 2019-10-24 18:28:45 PDT
*** Bug 43757 has been marked as a duplicate of this bug. ***