> On 03/01/2014 03:52 AM, Jan Hubicka wrote:
> >>a hidden function. We don't do that for user-defined virtual
> >>functions because the user controls whether or not they are defined
> >>in the header, and we don't devirtualize if no definition is
> >>available, but implicitly-declared functions are different because
> >>the user has no way to prevent the definition from being available.
> >>
> >>This also isn't a problem for cprop devirtualization, because in
> >>that situation we must have already referred to the vtable.
> >
> >Is this always the case? For normal virtual method you can have something
> >like:
> >
> >foo(class bla a)
> >{
> > a->bar();
> >}
> >
> >Here we will devirutalize bar into bla's method without ever seeing the
> >vtable.
> >I am not sure if I can construct a testcase for dtor w/o referencing the
> >vtable, since generally those are cases where dtor is generated autmatically.
> >But it is a bit fragile assumption to be made.
>
> For pass-by-value we need to be able to call a constructor, which
The call may live in other DSO, but I agree it is weird.
> needs to be able to reference the vtable, so I think it should be OK
> typically. Sure, people can do all kinds of weird and broken things
> with visibility; I'm just trying to make what seems to be a common
> and understandable pattern work.
Yes, this seems resonable. I guess I will need to find some central place
where to document those little implementation decisions (there are some
in can_refer_in_current_unit_p, some in visibility logic and some in the
new devirt logic)
Honza
>
> Jason
