Replace the "what I need to do" section of the RemoveDIs docs with a paragraph about preserving start-of-block iterators. Hopefully this is concise enough to remain in peoples heads going forwards!
Since the migration from `@llvm.dbg.value` intrinsic to `#dbg_value` records, there is no way to retrieve the debug records for an `Instruction` in LLVM-C API. Previously, with debug info intrinsics, retrieving debug info for an `Instruction` could be done with `LLVMGetNextInstructions`, because the intrinsic call was also an instruction. However, to be able to retrieve debug info with the current LLVM, where debug records are used, the `getDbgRecordRange()` iterator needs to be exposed. Add new functions for DbgRecord sequence traversal: LLVMGetFirstDbgRecord LLVMGetLastDbgRecord LLVMGetNextDbgRecord LLVMGetPreviousDbgRecord See llvm/docs/RemoveDIsDebugInfo.md and release notes.
The DIBuilder C API was changed to deal with DbgRecord functions: https://github.com/llvm/llvm-project/pull/84915 https://github.com/llvm/llvm-project/pull/85657 https://github.com/llvm/llvm-project/pull/92417#issuecomment-2120078326 As discussed by @nikic and @OCHyams: https://github.com/llvm/llvm-project/pull/92417#issuecomment-2144505440 > For the intrinsic-inserting functions, do you think we should: > > a) mark as deprecated but otherwise leave them alone for now. > b) mark as deprecated and change their behaviour so that they > do nothing and return nullptr. > c) outright delete them (it sounds like you're voting this one, > but just wanted to double check). This patch implements option (c).
Related review: https://github.com/llvm/llvm-project/pull/91724 This patch updates the RemoveDIs migration document to include details on the textual IR changes, including steps to update any downstream lit tests accordingly. These steps are the same as those used to update the lit tests in the LLVM/Clang lit tests, as detailed in the review linked above.
Add `LLVMPositionBuilderBeforeDbgRecords` and `LLVMPositionBuilderBeforeInstrAndDbgRecords` to `llvm/include/llvm-c/Core.h` which behave the same as `LLVMPositionBuilder` and `LVMPositionBuilderBefore` except that the position is set before debug records attached to the target instruction (the existing functions set the insertion point to after any attached debug records). More info on debug records and the migration towards using them can be found here: https://llvm.org/docs/RemoveDIsDebugInfo.html The distinction is important in some situations. An important example is when inserting a phi before another instruction which has debug records attached to it (these come "before" the instruction). Inserting before the instruction but after the debug records would result in having debug records before a phi, which is illegal. That results in an assertion failure: `llvm/lib/IR/Instruction.cpp:166: Assertion '!isa<PHINode>(this) && "Inserting PHI after debug-records!"' failed.` In llvm (C++) we've added bit to instruction iterators that carries around the extra information. Adding dedicated functions seemed like the least invasive and least suprising way to update the C API. Update llvm/tools/llvm-c-test/debuginfo.c to test this functionality. Update the OCaml bindings, the migration docs and release notes.
Although the patch that enables debug records by default has been temporarily reverted, it will (eventually) be reverted and everyone's code will be subjected to the new debug info format. Although this is broadly a good thing, it is important that the documentation has enough information to guide users through the update; this patch adds what should hopefully be enough detail for most users to either find the answers, or find out how to find those answers.
Follow on from #84915 which adds the DbgRecord function variants. The C API
changes were reviewed in #85657.
# C API
Update the LLVMDIBuilderInsert... functions to insert DbgRecords instead
of debug intrinsics.
LLVMDIBuilderInsertDeclareBefore
LLVMDIBuilderInsertDeclareAtEnd
LLVMDIBuilderInsertDbgValueBefore
LLVMDIBuilderInsertDbgValueAtEnd
Calling these functions will now cause an assertion if the module is in the
wrong debug info format. They should only be used when the module is in "new
debug format".
Use LLVMIsNewDbgInfoFormat to query and LLVMSetIsNewDbgInfoFormat to change the
debug info format of a module.
Please see https://llvm.org/docs/RemoveDIsDebugInfo.html#c-api-change
(RemoveDIsDebugInfo.md) for more info.
# OCaml bindings
Add set_is_new_dbg_info_format and is_new_dbg_info_format to the OCaml bindings.
These can be used to set and query the current debug info mode. These will
eventually be removed, but are useful while we're transitioning between old and
new debug info formats.
Add string_of_lldbgrecord, like string_of_llvalue but prints DbgRecords.
In test dbginfo.ml, unconditionally set the module debug info to the new mode
and update CHECK lines to check for DbgRecords. Without this change the test
crashes because it attempts to insert DbgRecords (new default behaviour of
llvm_dibuild_insert_declare_...) into a module that is in the old debug info
mode.
This reverts commit 2091c74796b1dac68e622284c63a870b88b7554f. Builtbot failure: https://lab.llvm.org/buildbot/#/builders/16/builds/63080
Follow on from #84915 which adds the DbgRecord function variants.
Update the LLVMDIBuilderInsert... functions to insert DbgRecords instead
of debug intrinsics.
LLVMDIBuilderInsertDeclareBefore
LLVMDIBuilderInsertDeclareAtEnd
LLVMDIBuilderInsertDbgValueBefore
LLVMDIBuilderInsertDbgValueAtEnd
Calling these functions will now cause an assertion if the module is in the
wrong debug info format. They should only be used when the module is in "new
debug format".
Use LLVMIsNewDbgInfoFormat to query and LLVMSetIsNewDbgInfoFormat to change the
debug info format of a module.
Please see https://llvm.org/docs/RemoveDIsDebugInfo.html#c-api-change
(RemoveDIsDebugInfo.md) for more info.
Another trivial rename patch, the last big one for now, which renamed DPMarkers to DbgMarkers. This required the field `DbgMarker` in `Instruction` to be renamed to `DebugMarker` to avoid a clash, but otherwise was a simple string substitution of `s/DPMarker/DbgMarker` and a manual renaming of `DPM` to `DM` in the few places where that acronym was used for debug markers.