[DebugInfo] Suppress template parameter information in the skeleton CU.

[Sockke]

Suppress template parameter information to optimize gmlt-like inline scope information in the skeleton CU.

Such information may not need to be copied to the skeleton CU?

A project within ByteDance enabled flags such as -fsplit-dwarf-inlining and -O3, resulting in a 5% reduction in overall size, with the debug_info section reduced by over 30%:

[llvmbot]

@llvm/pr-subscribers-debuginfo

Author: Liu Ke (Sockke)

Changes

Suppress template parameter information to optimize gmlt-like inline scope information in the skeleton CU.

Such information may not need to be copied to the skeleton CU?

A project within ByteDance enabled flags such as -fsplit-dwarf-inlining and -O3, resulting in a 5% reduction in overall size, with the debug_info section reduced by over 30%:
<img width="3448" height="1634" alt="image" src="https://github.com/user-attachments/assets/5b5041e7-e106-4711-a56d-a41e9c5b6b74" />

---

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

2 Files Affected:

• (modified) llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp (+2-1)
• (modified) llvm/test/DebugInfo/X86/fission-template.ll (+1-3)

diff --git a/llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp b/llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
index 330fe333a58cc..b7e603c58792b 100644
--- a/llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
+++ b/llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
@@ -1420,7 +1420,8 @@ bool DwarfUnit::applySubprogramDefinitionAttributes(const DISubprogram *SP,
   }
 
   // Add function template parameters.
-  addTemplateParams(SPDie, SP->getTemplateParams());
+  if (!Minimal)
+    addTemplateParams(SPDie, SP->getTemplateParams());
 
   // Add the linkage name if we have one and it isn't in the Decl.
   StringRef LinkageName = SP->getLinkageName();
diff --git a/llvm/test/DebugInfo/X86/fission-template.ll b/llvm/test/DebugInfo/X86/fission-template.ll
index b45b650846d00..7faf7cc2fa973 100644
--- a/llvm/test/DebugInfo/X86/fission-template.ll
+++ b/llvm/test/DebugInfo/X86/fission-template.ll
@@ -20,9 +20,7 @@
 ; CHECK:          DW_TAG_subprogram
 ; CHECK-NEXT:     DW_AT_linkage_name	("_Z2f2IiEvv")
 ; CHECK-NEXT:     DW_AT_name	("f2<int>")
-; CHECK:          DW_TAG_template_type_parameter
-; CHECK-NEXT:       DW_AT_type	(0x{{.*}} "int")
-; CHECK-NEXT:       DW_AT_name	("T")
+; CHECK-NOT:      DW_TAG_template_type_parameter
 ; CHECK:      .debug_info.dwo contents:
 ; CHECK:        DW_TAG_compile_unit
 ; CHECK:          DW_TAG_subprogram

[dwblaikie]

Presumably we still want the template parameters if we're using simplified template names - but we don't really have a way to detect that at this point, maybe? Not sure if it's adequate to check if the name has a "<" and ">" in it (because that might trip up from operator overloads, etc? maybe? (spaceship operator?))

[Sockke]

Thanks for your review, here are some of my ideas:

1. Pass DebugSimpleTemplateNames to the backend, and avoid creating template parameter information in the skeleton CU when in Full mode.
2. Provide an option similar to -gsuppress-template-params-in-skeleton-cu to dynamically control the behavior of creating template parameter information in the skeleton CU, which can support more scenarios, such as not focusing on the complete template name in Simple mode.

Do you have any suggestions?

[dwblaikie]

Thanks for your review, here are some of my ideas:

1. Pass DebugSimpleTemplateNames to the backend, and avoid creating template parameter information in the skeleton CU when in Full mode.
2. Provide an option similar to -gsuppress-template-params-in-skeleton-cu to dynamically control the behavior of creating template parameter information in the skeleton CU, which can support more scenarios, such as not focusing on the complete template name in Simple mode.

Do you have any suggestions?

Yeah, it's a bit of an awkward situation having to make choices at the LLVM layer about simplified template names...

Flags won't quite be adequate - because not /all/ names are simplified (and command line flags/backend options don't survive through LTO, which is a problem - and in LTO you might have a mix of simplified names from some input modules and unsimplified names from others).

I guess, ideally - perhaps we could use a bit on DICompositeType and DISubprogram's flags to say whether the name has been simplified? Not sure if we have lots of bits to spare in the flags on those types? Probably worth a discourse RFC about using another flag bit for this if that's the direction we might go.

That said, with my Google hat on, I'm not sure we care that much about split-dwarf-inlining these days (& not too many other folks care about simplified template names) so if there's no real overlap between the users of the two features, maybe it's not worth worrying too much about them working well together.

Do your use cases care about Simplified Template Names/are you using it or considering using it? (if you're using Split DWARF, presumably you care about debug info size somewhat, and simplified template names is a useful tool to address some debug info size issues in certain situations at least - so perhaps you're interested in it?)

[ayermolo]

How will this impact tools like symbolizers? Which I think is the main reason -fsplit-dwarf-inlining exists?
On side note, with split-dwarf support is not much more stable is it time to maybe deprecate this option?

[Sockke]

I guess, ideally - perhaps we could use a bit on DICompositeType and DISubprogram's flags to say whether the name has been simplified? Not sure if we have lots of bits to spare in the flags on those types? Probably worth a discourse RFC about using another flag bit for this if that's the direction we might go.

Thank you for the detailed explanation. I'm currently drafting an RFC to discuss this proposal.

Do your use cases care about Simplified Template Names/are you using it or considering using it? (if you're using Split DWARF, presumably you care about debug info size somewhat, and simplified template names is a useful tool to address some debug info size issues in certain situations at least - so perhaps you're interested in it?)

We haven't enabled this option yet, nor have we encountered scenarios where .debug_str overflows. In fact, overflow issues in .debug_info have been more common.

How will this impact tools like symbolizers? Which I think is the main reason -fsplit-dwarf-inlining exists?

In some distributed scenarios, the symbolization tool often parses debugging information from only the binary file (such as for inline stack unwinding). This is because the separated debug information is stored remotely in the form of .dwp files and is typically not downloaded via network requests. Therefore, it is necessary to enable -fsplit-dwarf-inlining.

[dwblaikie]

I guess, ideally - perhaps we could use a bit on DICompositeType and DISubprogram's flags to say whether the name has been simplified? Not sure if we have lots of bits to spare in the flags on those types? Probably worth a discourse RFC about using another flag bit for this if that's the direction we might go.

Thank you for the detailed explanation. I'm currently drafting an RFC to discuss this proposal.

Thanks!

Do your use cases care about Simplified Template Names/are you using it or considering using it? (if you're using Split DWARF, presumably you care about debug info size somewhat, and simplified template names is a useful tool to address some debug info size issues in certain situations at least - so perhaps you're interested in it?)

We haven't enabled this option yet, nor have we encountered scenarios where .debug_str overflows. In fact, overflow issues in .debug_info have been more common.

In Split DWARF - the 32 bit offsets in the DWP cu_index are overflowing, I guess? Are you using Type Units? (-fdebug-types-section - that would reduce the total size of .debug_info in the DWP at least)

How will this impact tools like symbolizers? Which I think is the main reason -fsplit-dwarf-inlining exists?

In some distributed scenarios, the symbolization tool often parses debugging information from only the binary file (such as for inline stack unwinding). This is because the separated debug information is stored remotely in the form of .dwp files and is typically not downloaded via network requests. Therefore, it is necessary to enable -fsplit-dwarf-inlining.

I guess the question might be "how does this affect the symbolizer results" - in the case of non-simplified template names, it should not affect symbolizer results. Symbolizers wouldn't generally look at template parameters - they'd just use the name. (but with simplified template names a symbolizer does have to look at the template parameters to reconstruct the names)

[Sockke]

I've submitted RFC: #89395