Version 2 was added more than two years ago (https://github.com/llvm/llvm-project/commit/6015a045d768feab3bae9ad9c0c81e118df8b04a). So it should be safe to deprecate older versions.
Fetch the DILocation once, instead of many times. This is pretty trivial, but goes through out-of-line code.
Patch 3/4 adding bitcode support, though the final patch doesn't depend on this one. Prior to this patch, a Key Instructions function inlined into a Not-Key-Instructions function fell back to Not-Key-Instructions handling. In order to fully support inlining mixed modes we need to run `computeKeyInstructions` (in case there's a Key Instructions scope) and `findForceIsStmtInstrs` (in case there's a Not-Key-Instructions scope) on all functions. This has a slight performance cost for all configurations - see PR for details.
Patch 2/4 adding bitcode support. A non-key-instructions function inlined into a key-instructions function uses non-key-instructions is_stmt placement (without `findForceIsStmtInstrs`). A key-instructions function inlined into a non-key-instructions function currently results in falling back to non-key-instructions for the inlined scope too. Both of these concessions (not using `findForceIsStmtInstrs` in the 1st case, and not using Key Instructions for the inlined scope in the 2nd) are for performance reasons; to do the right thing we'd need to run both `findForceIsStmtInstrs` and `computeKeyInstructions` - in case that's controversial I've got a separate PR for that: PR 144103.
MCExpr::print has an optional MCAsmInfo argument, which is error-prone when omitted. MCExpr::print and the convenience helper operator<< are discouraged to use. Switch to MCAsmInfo::printExpr instead. Use the target-specific MCAsmInfo if available.
`enum VariantKind` is deprecated. Targets are encouraged to use their own relocation specifier constants. MCSymbolRefExpr::create callers with a VK_None argument should switch to the overload with a VariantKind parameter.
Reapply "[NFC][DebugInfo][DWARF] Create new low-level dwarf library (#…
(#145959)
This reapplies cbf781f0bdf2f680abbe784faedeefd6f84c246e, with fixes for
the shared-library build and the unconventional sanitizer-runtime build.
Original Description:
This is the culmination of a series of changes described in [1].
Although somewhat large by line count, it is almost entirely mechanical,
creating a new library in DebugInfo/DWARF/LowLevel. This new library has
very minimal dependencies, allowing it to be used from more places than
the normal DebugInfo/DWARF library--in particular from MC.
1.
https://discourse.llvm.org/t/rfc-debuginfo-dwarf-refactor-into-to-lower-and-higher-level-libraries/86665/2
…145081)" This reverts commit cbf781f0bdf2f680abbe784faedeefd6f84c246e. Breaks a couple of buildbots.
This is the culmination of a series of changes described in [1].
Although somewhat large by line count, it is almost entirely mechanical,
creating a new library in DebugInfo/DWARF/LowLevel. This new library has
very minimal dependencies, allowing it to be used from more places than
the normal DebugInfo/DWARF library--in particular from MC.
I am happy to put it in another location, or to structure it differently
if that makes sense. Some have suggested in BinaryFormat, but it is not
a great fit there. But if that makes more sense to the reviewers, I can
do that.
Another possibility would be to use pass-through headers to allow
clients who don't care to depend only on DebugInfo/DWARF. This would be
a much less invasive change, and perhaps easier for clients. But also a
system that hides details.
Either way, I'm open.
1.
https://discourse.llvm.org/t/rfc-debuginfo-dwarf-refactor-into-to-lower-and-higher-level-libraries/86665/2