diff options
author | Jeremy Morse <jeremy.morse@sony.com> | 2024-02-07 15:31:59 +0000 |
---|---|---|
committer | GitHub <noreply@github.com> | 2024-02-07 15:31:59 +0000 |
commit | aeb58844dd6673417ebd7fb83f3acdf7282397fb (patch) | |
tree | fa2db11509d3ef29b499b813644df3edb5072f21 /llvm/lib/Bitcode/Reader/BitcodeReader.cpp | |
parent | 7a71ac2b00cd6ec06c113f8813f085d5ed346ad9 (diff) | |
download | llvm-aeb58844dd6673417ebd7fb83f3acdf7282397fb.zip llvm-aeb58844dd6673417ebd7fb83f3acdf7282397fb.tar.gz llvm-aeb58844dd6673417ebd7fb83f3acdf7282397fb.tar.bz2 |
[RemoveDIs] Don't convert debug-info in bitcode-loading just now (#80865)
We've been building and testing this no-debug-intrinsic work inside of
the pass manager for a while, so that optimisation passes get exercised
and tested when we turn it on. However, by converting to the
non-intrinsic form in the bitcode loader, we accidentally caused all
parts of LLVM to potentially see non-intrinsic debug-info.
Seeing how we're trying to turn things on incrementally, it was a
mistake to go this far this fast: we can instead just focus on enabling
during optimisations for the moment, then all the other parts of LLVM
later.
Diffstat (limited to 'llvm/lib/Bitcode/Reader/BitcodeReader.cpp')
-rw-r--r-- | llvm/lib/Bitcode/Reader/BitcodeReader.cpp | 19 |
1 files changed, 0 insertions, 19 deletions
diff --git a/llvm/lib/Bitcode/Reader/BitcodeReader.cpp b/llvm/lib/Bitcode/Reader/BitcodeReader.cpp index 5b233fb..515a1d0 100644 --- a/llvm/lib/Bitcode/Reader/BitcodeReader.cpp +++ b/llvm/lib/Bitcode/Reader/BitcodeReader.cpp @@ -6632,9 +6632,6 @@ Error BitcodeReader::materialize(GlobalValue *GV) { if (Error Err = materializeMetadata()) return Err; - bool NewDebugInfoRequested = F->IsNewDbgInfoFormat; - F->IsNewDbgInfoFormat = false; - // Move the bit stream to the saved position of the deferred function body. if (Error JumpFailed = Stream.JumpToBit(DFII->second)) return JumpFailed; @@ -6710,14 +6707,6 @@ Error BitcodeReader::materialize(GlobalValue *GV) { // Look for functions that rely on old function attribute behavior. UpgradeFunctionAttributes(*F); - // If we've materialized a function set up in "new" debug-info mode, the - // contents just loaded will still be in dbg.value mode. Switch to the new - // mode now. NB: we can add more complicated logic here in the future to - // correctly identify when we do and don't need to autoupgrade. - if (NewDebugInfoRequested) { - F->convertToNewDbgValues(); - } - // Bring in any functions that this function forward-referenced via // blockaddresses. return materializeForwardReferencedFunctions(); @@ -8042,14 +8031,6 @@ BitcodeModule::getModuleImpl(LLVMContext &Context, bool MaterializeAll, return std::move(Err); } - // If we are operating in a "new debug-info" context, upgrade the debug-info - // in the loaded module. This is a transitional approach as we enable "new" - // debug-info in LLVM, which will eventually be pushed down into the - // autoupgrade path once the bitcode-encoding is finalised. Non-materialised - // functions will be upgraded in the materialize method. - if (UseNewDbgInfoFormat && !M->IsNewDbgInfoFormat) - M->convertToNewDbgValues(); - return std::move(M); } |