[llvm] [Bitcode][NFC] Add abbrev for FUNC_CODE_DEBUG_LOC (PR #146497)

[Orlando Cazalet-Hyams via llvm-commits]

OCHyams wrote:

@dblaikie:
> I wonder if there's any way to reduce that impact - can't make the abbrev condition on debug info, I guess - too early to know that. The bitcode format does dynamically create abbrevs - but I guess if you don't create explicit ones like this, they aren't shared? Each record has its own abbrev? What if we had a way to add shared abbrevs dynamically?

I just tried dynamic abbrevs (to be clear, creating them in function blocks on the fly rather than declaring them up front in function block-info) but it seems you still need to bump the CodeLen from 4 to 5 bits. And looking at the file sizes it seems Jeremy is right that it's the CodeLen increase that's causing the size increase for non-debug builds. Using dynamic abbrevs reduces the savings in debug info builds slightly compared to the initial patch, but it's still pretty good wins overall:
* [trunk vs dynamic abbrevs](https://llvm-compile-time-tracker.com/compare.php?from=75cf826849713c00829cdf657e330e24c1a2fd03&to=536bba8ccc83fba67c58ec7234e3117a294215a9&stat=size-file&details=on)
* [block-info vs dynamic abbrevs](http://llvm-compile-time-tracker.com/compare.php?from=bdde57a859d344d9c6195dc6cbf797b327b6243e&to=536bba8ccc83fba67c58ec7234e3117a294215a9&stat=size-file&details=on) - to see the regression vs 1st patch attempt 
* (see patch summary for trunk vs block-info).

@jmorse:
> Customising the abbrev width based on whether the module contains debug-info feels awkward

I'll happily give this a go, but this may not be necessary depending on the results below.

@nikita:
> But if you want to preserve the size, I strongly suspect that you can kick out FUNCTION_INST_UNOP_ABBREV and FUNCTION_INST_UNOP_FLAGS_ABBREV without much impact.

[base vs remove-unop-abbrevs](https://llvm-compile-time-tracker.com/compare.php?from=7354123c34e658e990559a36b1ac7eb0b671e317&to=67a9230da31039f77f7a2a61ad012fd1acda9440&stat=size-file&details=on)

There's a slight saving in most non-debug files, but a reasonable regression in a few, e.g. stage1-ReleaseThinLTO CMakeFiles/lencod.dir/context_ini.c.o  83KiB -> 83KiB (+0.48%) (up to 0.9% for [gim_tri_collision.cpp](https://github.com/llvm/llvm-test-suite/blob/main/MultiSource/Benchmarks/Bullet/gim_tri_collision.cpp) which is a small - 500loc - file with a bunch of fp stuff). By my count the average across the .bc files is -0.047% for the non-debug thinLTO build and -0.021% for the debug LTO build. So overall it's a slight win for CTMark looking at percentages (I didn't get numbers for sum size difference, but can if needed).

If everyone's happy with us deferring smart conditional-on-debug-info stuff to a later date, in favour of Nikita's suggestion, then this seems like a good option to me. (I'll put up a PR shortly)

https://github.com/llvm/llvm-project/pull/146497