[Lldb-commits] [PATCH] D50071: Use rich mangling information in Symtab::InitNameIndexes()

[Stefan Gränitz via Phabricator via lldb-commits]

sgraenitz added a comment.

I quickly realized, that it needs a bigger change to properly address the aforementioned issues. Here's the major changes. Some documentation is todo.

**StringRef to reused buffer** addressed with a split into first parse then get buffer. It seems more natural that the buffer may be reused. Also we can ask for `const char *` or a `StringRef`, which avoids the conversion issue.

  MC.ParseFunctionBaseName();
  llvm::StringRef base_name = MC.GetBufferRef();
  [...]
  MC.ParseFunctionDeclContextName();
  const char *decl_context_cstr = MC.GetBufferAsCString();

**buffer size in, string length out on success, buffer size out on fail** is addressed in `processIPDStrResult`. It handles fails, reallocs and the regular cases and now distinguishes between `m_IPD_buf_size` and `m_IPD_str_len`.`RichManglingContext` maintains a single buffer now that is reused for all string-queries for Itanium. The fallback case always uses `ConstString` now and it may be a bit slower than before, but IMHO that's fine.

This change made the separation between `RichManglingInfo` and `RichManglingContext` unsustainable. So I merged them and now there are these ugly `None` cases, but otherwise it looks ok. I didn't adjust class and file names yet.

I touched the bookkeeping in `Symtab::InitNamesIndexes()` and added `Symtab::RegisterBacklogEntry()`.

I did some benchmarking. The LLDB integrated timers add so much overhead that the numbers are not really helpful. Xcode Instruments gave good results (I can do it with the old impl on Monday). This is from `lldb -b -- /path-to-ninja-build/relwithdebinfo/bin/clang`:

  16.00 ms   2.7%  Symtab::PreloadSymbols()
  16.00 ms   2.7%    Symtab::InitNameIndexes()
   7.00 ms   1.1%      Mangled::DemangleWithRichManglingInfo(RichManglingConte...
   3.00 ms   0.5%        ConstString::SetCStringWithMangledCounterpart(char co...
   3.00 ms   0.5%        Pool::GetConstCStringAndSetMangledCounterPart(char co...
   2.00 ms   0.3%        RichManglingContext::ParseFullName() const
   1.00 ms   0.1%        lldb_skip_name(llvm::StringRef, Mangled::ManglingScheme)
   1.00 ms   0.1%        RichManglingContext::FromItaniumName(ConstString const&)
   4.00 ms   0.6%      Mangled::GuessLanguage() const
   4.00 ms   0.6%        Mangled::GetDemangledName(lldb::LanguageType) const
   2.00 ms   0.3%      Symtab::RegisterMangledNameEntry(UniqueCStringMap<unsig...



================
Comment at: source/Core/RichManglingInfo.cpp:126
+  case ItaniumPartialDemangler: {
+    auto multi_in_out = m_IPD_size;
+    auto buf = m_IPD.getFunctionBaseName(m_IPD_buf, &multi_in_out);
----------------
Not sure about `multi_in_out` as a name here. It's hard to find one that fits the purpose and stays below 30 chars.. IPD calls it `N`.


https://reviews.llvm.org/D50071