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.
>
> Thanks for clarification. Comparing vtable addresses was the first use case
> and I got a prototype and got [wins mentioned
> above](https://github.com/llvm/llvm-project/pull/66825#issuecomment-1741534866).
> One test case (https://gcc.godbolt.org/z/eqvz4WxGM) pasted into godbolt, and
> auto-generated `ICALL-FUNC` `ICALL-VTABLE` elaborates the expected
> transformations. Besides selective vtable comparison, I'm planning to work on
> the [dynamic type
> propagation](https://github.com/llvm/llvm-project/pull/66825#issuecomment-1741560195).
>
> I could send out a draft patch about the vtable comparison (and thinlto
> import of the vtable variables) and a small RFC in the next few days.
Okay I think we're targeting different cases. My scenario is AutoFDO without
value profiling: relying on branch samples and optimizing if a member function
is unique to a vtable. The result is ultimately the same where we change the
code to compare directly against the vtable. @teresajohnson @david-xl any
objections to me starting this work?
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
