Quuxplusone
commented
6 years ago (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 :)
check_cfc.sh(3897 bytes, application/x-shellscript)test_err.log(25406 bytes, text/x-log)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:
Compile a C program with/without -g, and check that the resulting text sections are identical.
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.