# Considerations when adding new bitcode records

**URL:** <https://discourse.llvm.org/t/considerations-when-adding-new-bitcode-records/77660>\
**Category:** IR & Optimizations\
**Tags:** lto, thinlto, debuginfo\
**Created:** [March 13, 2024, 2:48pm UTC](https://discourse.llvm.org/t/considerations-when-adding-new-bitcode-records/77660 "2024-03-13T14:48:28Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![OCHyams](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/ochyams/32/1968_2.png) [@OCHyams](https://discourse.llvm.org/u/OCHyams)\
**Post date:** [March 13, 2024, 2:48pm UTC](https://discourse.llvm.org/t/considerations-when-adding-new-bitcode-records/77660/1 "2024-03-13T14:48:28Z")

</div>

Considerations when adding new bitcode records

Over in [[RemoveDIs] Read/write DbgRecords directly from/to bitcode by OCHyams · Pull Request #83251 · llvm/llvm-project · GitHub](https://github.com/llvm/llvm-project/pull/83251) I’ve added a bitcode representation for DbgRecords, the non-instruction replacement for debug intrinsics ([more info here](https://discourse.llvm.org/t/rfc-instruction-api-changes-needed-to-eliminate-debug-intrinsics-from-ir/68939)).

The pull request has additional details, but at a high level:

The patch adds 5 new records types to the FunctionCodes bitcode number-space, and one function block-info abbrev. Incidentally, the abbrev uses the last value available without widening the code-length for FUNCTION\_BLOCK from 4 to 5 bits.

The patch doesn’t deal with auto-upgrading, which will come in a separate patch soon. With the current patch the bitcode reader converts everything back to the “old debug format” (debug intrinsics) after parsing. The plan is for the auto-upgrader to convert debug intrinsics to DbgRecords.

**My question is** : does this sound alright? I’ve not made bitcode changes before, so I’m not sure if there are extra processes or problems that I’ve not considered in my patch.

* * *

This change introduces a decent file size reduction for optimized-code bitcode files – see the stage1-ReleaseLTO-g section in [compile time tracker per-file sizes](https://llvm-compile-time-tracker.com/compare.php?from=3356818eed3224c50012f8ed2bfa046f2bc8e154&to=2aa349db8dd1baf5572ef03c3d2bacaebd0a312d&stat=size-file&details=on), savings ranging from 5-30%. LTO with debug goes a tiny bit faster too (I imagine as a result of the IO savings) ([compile time tracker](https://llvm-compile-time-tracker.com/compare.php?from=3356818eed3224c50012f8ed2bfa046f2bc8e154&to=2aa349db8dd1baf5572ef03c3d2bacaebd0a312d&stat=instructions), even with the temporary mode-conversion roundtrip after reading the bitcode).

---

<div class="post-metadata">

**Author:** ![teresajohnson](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/teresajohnson/32/2003_2.png) [@teresajohnson](https://discourse.llvm.org/u/teresajohnson)\
**Post date:** [March 14, 2024, 7:55pm UTC](https://discourse.llvm.org/t/considerations-when-adding-new-bitcode-records/77660/2 "2024-03-14T19:55:49Z")

</div>

This sounds reasonable to me. I don’t think there are issues with adding new record types beyond any object file size and related I/O compile time effects, and it sounds like you have done the measurements and it seems like a pretty clear win to me!

---

<div class="post-metadata">

**Author:** ![aeubanks](https://avatars.discourse-cdn.com/v4/letter/a/f6c823/32.png) [@aeubanks](https://discourse.llvm.org/u/aeubanks)\
**Post date:** [March 14, 2024, 8:01pm UTC](https://discourse.llvm.org/t/considerations-when-adding-new-bitcode-records/77660/3 "2024-03-14T20:01:11Z")

</div>

For autoupgrading, we can drop old debug info according to [LLVM Developer Policy — LLVM 19.0.0git documentation](https://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility).

---

<div class="post-metadata">

**Author:** ![OCHyams](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/ochyams/32/1968_2.png) [@OCHyams](https://discourse.llvm.org/u/OCHyams)\
**Post date:** [March 15, 2024, 9:39am UTC](https://discourse.llvm.org/t/considerations-when-adding-new-bitcode-records/77660/4 "2024-03-15T09:39:02Z")

</div>

Thanks @teresajohnson. I’ll land the patch today then (as it has already been approved).

> [@aeubanks](#):
>
> For autoupgrading, we can drop old debug info according to [LLVM Developer Policy — LLVM 19.0.0git documentation](https://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility).

Just checking - is there a reason we might _want_ to drop the debug info instead of upgrade it, if upgrading it is easy?

It’s trivial to perform the upgrade from debug intrinsic to DbgRecord (they can be swapped 1 for 1) and I’ve got a patch that does it (just needs tidying up before sharing).

---

<div class="post-metadata">

**Author:** ![pogo59](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/pogo59/32/2412_2.png) [@pogo59](https://discourse.llvm.org/u/pogo59)\
**Post date:** [March 15, 2024, 2:47pm UTC](https://discourse.llvm.org/t/considerations-when-adding-new-bitcode-records/77660/5 "2024-03-15T14:47:26Z")

</div>

> [@OCHyams](#):
>
> Just checking - is there a reason we might _want_ to drop the debug info instead of upgrade it, if upgrading it is easy?

The two forms are semantically equivalent, so I’d say no.