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'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.
https://github.com/llvm/llvm-project/pull/66825
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
