Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-89269

Things to explore when upgrading toolchain

    • Type: Icon: Task Task
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Labels:
    • Build

      A few things to consider in the 9.0 timeframe, especially after we bump the toolchain:

      • In addition to testing clang vs gcc, we should probably test libc++ vs libstdc++. This should probably be a 4-way comparison with both compilers each tested with both stdlibs (easy with clang, but requires some flag fiddling with gcc). At the very least, I know that libc++ has a much better implementation of std::string, and we may even want to stdx:: a similar implementation if we stick to libstdc++.
      • We should strongly consider enabling LIBCXX_ABI_UNSTABLE when building llvm/libc++. It enables a lot of improvements and optimizations that can't be turned on by default because it would be an ABI break. But since we embed the stdlib in our release binaries, we are fine taking that ABI break. Of note, this enables an even better std::string and enables shared_ptr and unique_ptr to be passed in registers when passed by value (only on clang unfortunately).
      • When testing clang, we should mark some important types with [[clang::trivial_abi]], including at least Value, BSONObj, and boost::intrusive_pointer. This will both allow them to be passed and returned in registers, as well as make vectors of them use memcpy for growth on libc++. boost::intrusive_ptr will automatically take care of many types (SharedBuffer, Message, Document, etc) and is required for at least BSONObj and Future. We can either modify our vendored copy of the boost sources (easiest to POC), or we can just copy its small implementation into mongo:: and find-replace all usages.

      I've put these together since they have some interplay and should probably be considered together. For example, clang's support of trivial_abi and the unstable libc++ ABI may be enough to push it over into being faster than gcc, even if it wouldn't be with our current codebase and build flags.

            Assignee:
            Unassigned Unassigned
            Reporter:
            mathias@mongodb.com Mathias Stearn
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: