[PATCH] D85628: [HotColdSplitting] Add command line options for supplying cold function names via user input.

Jay Feldblum via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Aug 12 16:01:30 PDT 2020


yfeldblum added a comment.

In D85628#2214138 <https://reviews.llvm.org/D85628#2214138>, @hiraditya wrote:

> For example: https://godbolt.org/z/ThaGEW the constructor of static object is always cold, how can we outline this if say we don't have a profile information. A workload can have a set of cold functions which programmer would know, but they necessarily don't have profile information. If there's a better way to make compiler aware of this, I'll be more than happy to work on that.

I don't think we need to mark the object constructor as cold. We want to mark inlined slow paths of local static variables (the call to `__cxa_guard_acquire`, the call to the object constructor, etc.,) as cold.

As one possibility the consequences of which I have certainly not thought through, but which maybe already exists to some degree, we can depend on a bit of inference - if `__cxa_guard_acquire` is marked as cold, then all code which is accessible only by passing the call to `__cxa_guard_acquire` is also cold. Intuition: blocks which *contain* unconditional cold code are themselves cold by transitivity. Intuition: don't call cold functions where you're not cold.

  [[gnu::cold]] void cold_func();
  void has_cold_branch(bool b) {
    // nothing here is cold
    if (b) {
      // everything here is cold
      cold_func();
      // everything here is cold
    } else {
      // nothing here is cold
    }
    // nothing here is cold
  }

In particular, this would hopefully mean that the object constructor call which appears past the `__cxa_guard_acquire` would not get inlined into the call-site; rather, a call to the constructor would be emitted. (Unless inlining the constructor into the call-site is shorter than calling the constructor.) In this case, we would not compile the object constructor optimized for coldness - we would compile the object constructor as normal. In fact, since the same constructor is used in hot paths, we must not compile it as cold. But we would compile the call-site as though it were cold, since `__cxa_guard_acquire` is marked cold and this call site unconditionally passes through `__cxa_guard_acquire`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D85628/new/

https://reviews.llvm.org/D85628



More information about the llvm-commits mailing list