Considerations when adding new bitcode records

IR & Optimizations
, ,
1

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 I’ve added a bitcode representation for DbgRecords, the non-instruction replacement for debug intrinsics (more info here).

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, 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, even with the temporary mode-conversion roundtrip after reading the bitcode).

2

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!

1 Like
3

For autoupgrading, we can drop old debug info according to LLVM Developer Policy — LLVM 19.0.0git documentation.

4

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

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).

5

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