Skip to content
  1. Aug 09, 2018
  2. Aug 08, 2018
    • Stefan Granitz's avatar
      Add ConstString test FromMidOfBufferStringRef · 4c01eccb
      Stefan Granitz authored
      Summary: It was not immediately clear to me whether or not non-null-terminated StringRef's are supported in ConstString and/or the counterpart mechanism. From this test it seems to be fine. Maybe useful to keep?
      
      Reviewers: labath
      
      Subscribers: lldb-commits
      
      Differential Revision: https://reviews.llvm.org/D50334
      
      llvm-svn: 339292
      4c01eccb
    • Stefan Granitz's avatar
      Use rich mangling information in Symtab::InitNameIndexes() · f1a98df6
      Stefan Granitz authored
      Summary:
      I set up a new review, because not all the code I touched was marked as a change in old one anymore.
      
      In preparation for this review, there were two earlier ones:
      * https://reviews.llvm.org/D49612 introduced the ItaniumPartialDemangler to LLDB demangling without conceptual changes
      * https://reviews.llvm.org/D49909 added a unit test that covers all relevant code paths in the InitNameIndexes() function
      
      Primary goals for this patch are:
      (1) Use ItaniumPartialDemangler's rich mangling info for building LLDB's name index.
      (2) Provide a uniform interface.
      (3) Improve indexing performance.
      
      The central implementation in this patch is our new function for explicit demangling:
      ```
      const RichManglingInfo *
      Mangled::DemangleWithRichManglingInfo(RichManglingContext &, SkipMangledNameFn *)
      ```
      
      It takes a context object and a filter function and provides read-only access to the rich mangling info on success, or otherwise returns null. The two new classes are:
      * `RichManglingInfo` offers a uniform interface to query symbol properties like `getFunctionDeclContextName()` or `isCtorOrDtor()` that are forwarded to the respective provider internally (`llvm::ItaniumPartialDemangler` or `lldb_private::CPlusPlusLanguage::MethodName`).
      * `RichManglingContext` works a bit like `LLVMContext`, it the actual `RichManglingInfo` returned from `DemangleWithRichManglingInfo()` and handles lifetime and configuration. It is likely stack-allocated and can be reused for multiple queries during batch processing.
      
      The idea here is that `DemangleWithRichManglingInfo()` acts like a gate keeper. It only provides access to `RichManglingInfo` on success, which in turn avoids the need to handle a `NoInfo` state in every single one of its getters. Having it stored within the context, avoids extra heap allocations and aids (3). As instantiations of the IPD the are considered expensive, the context is the ideal place to store it too. An efficient filtering function `SkipMangledNameFn` is another piece in the performance puzzle and it helps to mimic the original behavior of `InitNameIndexes`.
      
      Future potential:
      * `DemangleWithRichManglingInfo()` is thread-safe, IFF using different contexts in different threads. This may be exploited in the future. (It's another thing that it has in common with `LLVMContext`.)
      * The old implementation only parsed and indexed Itanium mangled names. The new `RichManglingInfo` can be extended for various mangling schemes and languages.
      
      One problem with the implementation of RichManglingInfo is the inaccessibility of class `CPlusPlusLanguage::MethodName` (defined in source/Plugins/Language/..), from within any header in the Core components of LLDB. The rather hacky solution is to store a type erased reference and cast it to the correct type on access in the cpp - see `RichManglingInfo::get<ParserT>()`. At the moment there seems to be no better way to do it. IMHO `CPlusPlusLanguage::MethodName` should be a top-level class in order to enable forward delcarations (but that is a rather big change I guess).
      
      First simple profiling shows a good speedup. `target create clang` now takes 0.64s on average. Before the change I observed runtimes between 0.76s an 1.01s. This is still no bulletproof data (I only ran it on one machine!), but it's a promising indicator I think.
      
      Reviewers: labath, jingham, JDevlieghere, erik.pilkington
      
      Subscribers: zturner, clayborg, mgorny, lldb-commits
      
      Differential Revision: https://reviews.llvm.org/D50071
      
      llvm-svn: 339291
      f1a98df6
    • Vedant Kumar's avatar
      [IRMemoryMap] Shrink Allocation and make it move-only (NFC) · f71dd344
      Vedant Kumar authored
      Profiling data show that Allocation::operator= is hot (see the data
      attached to the Phab review).
      
      Reorder a few fields within Allocation to avoid implicit structure
      padding and shrink the structure. This should make copies a bit cheaper.
      
      Also, given that an Allocation contains a std::vector (by way of
      DataBufferHeap), it's preferable to make it move-only instead of
      permitting expensive copies. As an added benefit this allows us to have
      a single Allocation constructor instead of two.
      
      Differential Revision: https://reviews.llvm.org/D50271
      
      llvm-svn: 339290
      f71dd344
    • Craig Topper's avatar
      Revert r339287 "[Builtins] Add __builtin_clrsb support to IntExprEvaluator::VisitBuiltinCallExpr" · 3e8820a0
      Craig Topper authored
      This add an additional unintended change in it.
      
      llvm-svn: 339289
      3e8820a0
    • Jonas Devlieghere's avatar
      [DWARF] Unclamp line table version on Darwin for v5 and later. · 49ff4d90
      Jonas Devlieghere authored
      On Darwin we pin the DWARF line tables to version 2. Stop doing so for
      DWARF v5 and later.
      
      Differential revision: https://reviews.llvm.org/D49381
      
      llvm-svn: 339288
      49ff4d90
    • Craig Topper's avatar
      [Builtins] Add __builtin_clrsb support to IntExprEvaluator::VisitBuiltinCallExpr · 9ff024a5
      Craig Topper authored
      This addresses a FIXME that has existed since before clang supported the builtin.
      
      Differential Revision: https://reviews.llvm.org/D50471
      
      llvm-svn: 339287
      9ff024a5
    • Michal Gorny's avatar
      [cmake] Append LLVM_VERSION_SUFFIX to SOVERSION · c4ede8f8
      Michal Gorny authored
      Append LLVM_VERSION_SUFFIX to SOVERSION. This makes it possible
      to use the suffix to differentiate binary-incompatible versions
      of LLVM built via BUILD_SHARED_LIBS.
      
      We are planning to use this to temporarily preserve ABI-incompatible
      variants of LLVM while switching the system between them, e.g. when
      rebuilding the system to use libc++. Normally this would mean that once
      LLVM is rebuilt using libc++ all the reverse dependencies become
      immediately broken. Using a distinct SOVERSION allows us to preserve
      the ABI compatibility before all the packages are rebuilt.
      
      Differential Revision: https://reviews.llvm.org/D39939
      
      llvm-svn: 339286
      c4ede8f8
    • Michal Gorny's avatar
      cmake: Store LLVM_VERSION_SUFFIX in LLVMConfig.cmake · 24cb754b
      Michal Gorny authored
      Store LLVM_VERSION_SUFFIX along with other version components
      in LLVMConfig.cmake. This fixes preserving the suffix set while building
      LLVM to stand-alone builds of other components, e.g. clang,
      and therefore improves uniformity between the two build models.
      
      Given that there is no apparent reason to omit this part of version,
      that it is distributed to subprojects when building as part of LLVM
      and that it is included in LLVM_PACKAGE_VERSION, I think it was omitted
      accidentally rather than done on purpose.
      
      Differential Revision: https://reviews.llvm.org/D43701
      
      llvm-svn: 339285
      24cb754b
Loading