tl;dr a patch is about to land that may break any downstream IR tests for debug info; this post explains why and how to handle it
What’s happening?
There has been a long ongoing work to replace debug intrinsics with debug records for various reasons; the purpose and design of this work is outside the scope of this post, but has been previously discussed at reasonable length(1, 2, 3), and is documented here.
This post is a warning that a patch will be landing imminently that will change the default output of LLVM from debug intrinsics to debug records. For the most part this is a straightforward mechanical change:
; Debug Intrinsic:
call void @llvm.dbg.value(metadata i32 %add, metadata !10, metadata !DIExpression()), !dbg !20
; Debug Record:
#dbg_value(i32 %add, !10, !DIExpression(), !20)
This applies to all the debug intrinsics, i.e. llvm.dbg.assign, llvm.dbg.declare, llvm.dbg.label, and llvm.dbg.value. As part of the patch that enables this, all upstream tests that test for debug intrinsics will be updated to test for debug records, except those that specifically seek to test debug intrinsics, essentially just verifier and IR printing/parsing tests. The patch will not update all test IR to contain debug records, only the CHECK directives, although such an update will be trivial to make if/when it happens.
What do I need to do?
All upstream tests should pass after the patch lands; I only have one machine to run the tests against however, so there may be tests that won’t run locally for me that I have missed. There will also be many downstream tests for debug intrinsics that will break after this patch lands. On the migration guide, there is a set of instructions on how to update IR tests for the new output; these instructions assume a unix shell, but if desired I could provide a translation for windows.
As a stop-gap measure it is possible to disable the use of debug records for specific tests by passing --write-experimental-debuginfo=false to LLVM’s option parser. If you have a large set of tests that are failing and aren’t able to quickly update all of them using the method above, adding this flag should quickly unblock your build. You could also do so preemptively if desired, though I highly recommend performing the update as at some point (likely in a future release) the flag will be removed. Only IR tests will be affected, so MIR and assembly/object emission will be unchanged, but this will include tests for subprojects that emit IR, e.g. clang, flang, or mlir.