This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Bare bones of virtual call tracking
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Jason Merrill <jason at redhat dot com>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, gcc-patches at gcc dot gnu dot org, mjambor at suse dot cz
- Date: Mon, 12 Aug 2013 18:21:59 +0200
- Subject: Re: [RFC] Bare bones of virtual call tracking
- References: <20130812121624 dot GF22678 at kam dot mff dot cuni dot cz> <5208FF6C dot 3060408 at redhat dot com>
> On 08/12/2013 08:16 AM, Jan Hubicka wrote:
> >With multiple inheritance I need to adjust offsets.
>
> It's not clear to me that you need to worry about that in your
> search. A call through a particular vptr can only call overrides
> that go into a vtable that vptr can point to, and you can look up
> any thunk adjustments from the vtable.
What I think I need to worry about is the case, where I have
type A with a virtual method FOO. I have call of FOO.
Now I have type B that inherits A with non-zero offset and overwrites
method FOO to FOO2.
Now call to FOO can be either FOO or FOO2, since someone can make
object of type B and cast it back to A.
How can look it up in B's representation?
>
> >+ /* First skip wrappers that C++ FE puts randomly into types. */
> >+ while (TREE_CODE (t) == TYPE_DECL
> >+ && DECL_ORIGINAL_TYPE (t))
>
> How can you get a decl in your types array?
Hmm, I am not sure if I can ;) I just copied the ODR code from tree.c.
Basically I start with RECORD_TYPE or so, look for TYPE_NAME that gives
me a type decl whose name is identifier. I hash it and recursively look
for context. I am not 100% sure what I can find in the contextes.
For sure there can be namespaces.
One thing I noticed is that I get multiple instances of same type in my
hash in LTO. It seems to be because TYPE_CANONICAL differs. I wonder
what of LTO type merging of TYPE_CANONICAl can mismatch with C++ style
ODR.
Honza
>
> Jason