This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][C++] Fix PR38334, TBAA issues with vtbl loads


On Tue, 2 Dec 2008, Mark Mitchell wrote:

> Richard Guenther wrote:
> 
> > optimization figured out that the memfun delta is zero, so if
> > D.1853_6 & 1 is true we load the vtbl pointer from the start of
> > the object in question (where there isn't such). 
> 
> I almost commented on this in the previous email, but hadn't realized
> that the delta was zero in your case.
> 
> If we can prove that the access is happening through a class that
> doesn't have a vtable (that is, the static type of the pointer is not a
> dynamic class), then we can turn that access into a call to
> __builtin_trap, or, even better, eliminate that entire conditional.
> 
> In other words, if the pointer-to-function-member is { delta: 0; ptr:
> <something> }, and the instance is not dynamic, then we can safely
> optimize by assuming that pointer-to-function-member is not to a virtual
> function.  That would be considerably better than trying to work around
> the aliasing issue.

Sure.  The problem is we only know after inlining and some non-trivial
optimization (and at this point nothing distinguishes the access from
other pointer arithmetic and accesses).  I can disable the spurious
warning easily if you tell me that if the vtbl load is not "dead" then
the referenced object does contain such a pointer (and we know that
by means of recording a proper alias relationship).

Thanks,
Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]