An update on how this project is all going: the good news is that with the relevant code paths on-by-default there haven’t been any pervasive crashes, and we get a 2% speedup on llvm-compile-time-tracker.com. (Which we can improve on a lot!). In doing so we’ve generated a decent amount of technical debt though that we’re working through:
- We need to finish replacing all instruction insertions with iterator-insertions. This is almost purely mechanical though, so just a chore that’s ongoing.
- Textual IR printing has landed, parsing is about to ([RemoveDIs][DebugInfo][IR] Add parsing for non-intrinsic debug values by SLTozer · Pull Request #79818 · llvm/llvm-project · GitHub)
- We have a patch up for bitcode support for the new format ([RemoveDIs] Read/write DbgRecords directly from/to bitcode by OCHyams · Pull Request #83251 · llvm/llvm-project · GitHub) which has substantial bitcode size savings.
- The DIBuilder interface needs updating to the new format (in-progress)
- We need to expand the portions of LLVM that have RemoveDIs on-by-default to include all the tools, not just the pass manager.
This is all stuff that’s in-progress: finalising everything into using the new format should be fairly quick once we’ve got all the terminals of LLVM supporting it. The biggest question mark for me is ensuring the bitcode format meets expectations: we’re using more of the FunctionCodes number-space and another abbrev code in the function block, which should be fine, but I don’t know if those resources are considered “rationed”.
We’ll start to convert LLVM-IR tests over to the new format once the above matters are settled (we’ll provide scripts for downstream tests). The current conversion of intrinsics to new debug-info records will eventually be pushed into the debug-info autoupgrade path.
We’re aware of a few rough edges – unoptimised -g builds are roughly 0.5% slower because of the conversion overhead (which we’ll eventually get rid of), while some unused-but-not-yet-freed metadata tracking DenseMaps are pushing up memory usage when we convert from RemoveDIs back to intrinsic format on emission. These should both disappear when we’re using the non-intrinsic form end-to-end.
Finally, as @hvdijk mentioned above, it’s turned out that what we thought was a minor risk of “a debug-record being displaced by one instruction” is actually a verifier error if it ends up mixing PHIs and debug records (after converting back to intrinsic-form). We realised this fairly late unfortunately; but it’s something that shouldn’t occur when inserting PHIs with iterators, as the background debug-info accounting takes care of that. The bulk updates I’ve been doing to get all optimisations inserting with iterators should now mean that doesn’t occur in any transform that’s in the monorepo.