[clang] [IRPGO][ValueProfile] Instrument virtual table address that could be used to do virtual table address comparision for indirect-call-promotion. (PR #66825)
via cfe-commits
cfe-commits at lists.llvm.org
Mon Oct 9 14:11:55 PDT 2023
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
More information about the cfe-commits
mailing list