modiking wrote:
> > > Yes there are tradeoffs to doing this purely with whole program class
> > > hierarchy analysis vs with profiled type info, and in fact they can be
> > > complementary. For example, the profile info can indicate what order to
> > > do the vtable comparisons (i.e. descending order of hotness, as we do for
> > > vfunc comparisons in current ICP), while WP CHA can be used to determine
> > > when no fallback is required. Also, another advantage of doing this with
> > > profiling is also that it does not require WP visibility, which may be
> > > difficult to guarantee.
> >
> >
> > Gotcha, that makes sense. Are there plans on your side to extend this level
> > of value profiling/WP CHA to AutoFDO? I'm looking into trying out the WP
> > CHA approach on my side since it looks like there are cases it can catch in
> > our internal workloads.
>
> AutoFDO support is a natural follow-up for profile-gen. I'm currently working
> on having more vtable comparisons with class-hierarchy-analysis and do more
> devirtualization with type information.
Can you elaborate on what cases your current work is targeting? I was planning
on starting work to catch the following:
```
class base
{
virtual int foo() = 0;
}
class derive1 : base
{
virtual int foo() {/*unique implementation*/};
}
class derive2 : base
{
virtual int foo() {/*unique implementation*/};
}
void callee(base* b)
{
b->foo(); // profile information indicates target is primarily derive2::foo()
}
```
Where we can directly compare vtable address instead of function address. If
you're already working on this case then I don't want to step on your toes and
just wait for your changes.
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
