[clang] [IRPGO][ValueProfile] Instrument virtual table address that could be used to do virtual table address comparision for indirect-call-promotion. (PR #66825)

Mingming Liu via cfe-commits cfe-commits at lists.llvm.org
Fri Sep 29 15:05:40 PDT 2023


minglotus-6 wrote:

> > > The work sounds interesting. Can you provide a bit more context about it? Will it be used to improve ICP when it's sufficient to just compare the vtable address instead of the vfunc address?
> > 
> > 
> > yes -- it can not only eliminate vtable load, but also enable target check combining.
> > What is more important is that it can be combined with more aggressive interprocedural type propagation that enables full (unconditional) devirtualization. Example:
> > base->foo(); base->bar(); ==> if (base->vptr == Derived) { Derived::foo(base); // base type is known so virtual calls in foo,bar can further be devirtualized. Derived::bar(base); } else {.. }
> 
> Thanks for the illustration! Have you enabled this in your fleet, and how much performance improvement have you seen?
> 
> We've been also thinking about similar work based on sample PGO, in both the compiler and bolt. cc @WenleiHe

I tested a prototype (using the simplest heuristic to do vtable comparison only if the distribution of vtable is the same as vfunc distribution) on one internal workloads. It shows a statistically significant +0.26% qps improvement on one search workload, gcu reductions on two other workloads and mostly neutral for a database. The numbers are initial without tuning (e.g., what about do vtable comparison if there are two vtable values and one function, etc)

https://github.com/llvm/llvm-project/pull/66825


More information about the cfe-commits mailing list