[BOLT][NFC] Unset UseAssemblerInfoForParsing for emission

[aaupov]

Summary:
Use workaround for quadratic behavior inside
AttemptToFoldSymbolOffsetDifference called from BinaryEmitter::emitLSDA.

b06e736#commitcomment-142836456

[llvmbot]

@llvm/pr-subscribers-bolt

Author: Amir Ayupov (aaupov)

Changes

Summary:
Use workaround for quadratic behavior inside
AttemptToFoldSymbolOffsetDifference called from BinaryEmitter::emitLSDA.

b06e736#commitcomment-142836456

---

Full diff: https://github.com/llvm/llvm-project/pull/94778.diff

1 Files Affected:

• (modified) bolt/lib/Core/BinaryEmitter.cpp (+2)

diff --git a/bolt/lib/Core/BinaryEmitter.cpp b/bolt/lib/Core/BinaryEmitter.cpp
index 0b44acb0816f2..5793963f9b80d 100644
--- a/bolt/lib/Core/BinaryEmitter.cpp
+++ b/bolt/lib/Core/BinaryEmitter.cpp
@@ -194,6 +194,7 @@ class BinaryEmitter {
 
 void BinaryEmitter::emitAll(StringRef OrgSecPrefix) {
   Streamer.initSections(false, *BC.STI);
+  Streamer.setUseAssemblerInfoForParsing(false);
 
   if (opts::UpdateDebugSections && BC.isELF()) {
     // Force the emission of debug line info into allocatable section to ensure
@@ -226,6 +227,7 @@ void BinaryEmitter::emitAll(StringRef OrgSecPrefix) {
   // TODO Enable for Mach-O once BinaryContext::getDataSection supports it.
   if (BC.isELF())
     AddressMap::emit(Streamer, BC);
+  Streamer.setUseAssemblerInfoForParsing(true);
 }
 
 void BinaryEmitter::emitFunctions() {

[MaskRay]

Any idea why there is a quadratic behavior? Is the LayoutOrder cache not utilized? The following code should only be executed once for each section.

        for (MCFragment &F : *FA->getParent())
          F.setLayoutOrder(++LayoutOrder);

If you have any smaller example, I am happy to investigate by myself. My arbitrary picking one bold/test test doesn't find any repeated execution pattern.

[aaupov]

Any idea why there is a quadratic behavior? Is the LayoutOrder cache not utilized? The following code should only be executed once for each section.

        for (MCFragment &F : *FA->getParent())
          F.setLayoutOrder(++LayoutOrder);

If you have any smaller example, I am happy to investigate by myself. My arbitrary picking one bold/test test doesn't find any repeated execution pattern.

The issue manifests only for large binaries with LSDA (C++ exceptions). RocksDB might be a suitable target. I can try to prepare the binary and add it to https://github.com/rafaelauler/bolt-tests

[MaskRay]

Any idea why there is a quadratic behavior? Is the LayoutOrder cache not utilized? The following code should only be executed once for each section.

        for (MCFragment &F : *FA->getParent())
          F.setLayoutOrder(++LayoutOrder);

If you have any smaller example, I am happy to investigate by myself. My arbitrary picking one bold/test test doesn't find any repeated execution pattern.

The issue manifests only for large binaries with LSDA (C++ exceptions). RocksDB might be a suitable target. I can try to prepare the binary and add it to rafaelauler/bolt-tests

Thanks! I guess you probably came to the wrong culprit b06e736 , which made me confused. The culprit for your use case might be the trigger #91082 .

LGTM. These getUseAssemblerInfoForParsing instances are tech debt, which I hope will be eliminated at some point...