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

[David Li via llvm-commits]

david-xl 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'm prototyping vtable comparison (to eliminate the additional load conditionally to avoid the downside mentioned https://groups.google.com/g/llvm-dev/c/_1kughXhjIY/m/7fzCmsuVmS8J) and it works for small test programs. I will collect the numbers for macro benchmarks.

There is a great potential with performance. It depends on transformation strategy, and other optimizations enabled by the type information. The legacy indirection promotion for virtual calls also need to be turned off after this is ready.

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