> > Currently my type graph is very partial - I have no nodes for types without
> > virtual methods at all.
>
> Those are not probably interesting anyways.
Forgot to mention, I think in longer term we can use it to maintain more of C++
type based aliasing rules. Currently we unify canonical types
> On Thu, Aug 15, 2013 at 9:46 AM, Jan Hubicka wrote:
> >> Some suggestions for the future:
> >>
> >> 1) add summary info in the odr dump -- i.e. for each node, dump the
> >> number of direct bases, direct subtypes, number of all bases, all
> >> subtypes;
> >
> > OK, can add that.
> >> 2) add stat
On Thu, Aug 15, 2013 at 9:46 AM, Jan Hubicka wrote:
>> Some suggestions for the future:
>>
>> 1) add summary info in the odr dump -- i.e. for each node, dump the
>> number of direct bases, direct subtypes, number of all bases, all
>> subtypes;
>
> OK, can add that.
>> 2) add statistics dump -- ave
> Some suggestions for the future:
>
> 1) add summary info in the odr dump -- i.e. for each node, dump the
> number of direct bases, direct subtypes, number of all bases, all
> subtypes;
OK, can add that.
> 2) add statistics dump -- average size of a hierarchy subgraph
>
> 3) Dump the graph usi
Some suggestions for the future:
1) add summary info in the odr dump -- i.e. for each node, dump the
number of direct bases, direct subtypes, number of all bases, all
subtypes;
2) add statistics dump -- average size of a hierarchy subgraph
3) Dump the graph using top-order -- starting from roots
> On 08/14/2013 02:14 AM, Jan Hubicka wrote:
> >As a temporary hack I suppose I can rely on assembler name of virtual table
> >to be unique for each templated class?
>
> Actually, that seems like a fine solution for devirtualization; just
> compare the mangled name of the vtable to establish type
On 08/14/2013 02:14 AM, Jan Hubicka wrote:
As a temporary hack I suppose I can rely on assembler name of virtual table
to be unique for each templated class?
Actually, that seems like a fine solution for devirtualization; just
compare the mangled name of the vtable to establish type identity.
Hi,
here is current patch that implements the inheritance graph construction and
reachable function lookup. I think I now understand binfos right. I added
record_binfo that basically does what get_binfo_at_offset does without
considering the offset (i.e. sort of get_binfo_at_any_offset) and I can
Jason,
I introduced an warning on ODR violations (i.e. when I hot two types that are
equivalent by my ODR code and have different canonical types). Unforutnately
this hits a false positives on template instantiations. Here my ODR code
apparently never sees the types of template parameters; just th
> It might be more flexible to represent the analysis results as a
> type/inheritance graph -- i.e. explicitly introduce inheritance edge
> class to capture the interitence relationship (offset, etc) between
> two class nodes. The 'method' should probably be augmented to include
Yep, that is gener
It might be more flexible to represent the analysis results as a
type/inheritance graph -- i.e. explicitly introduce inheritance edge
class to capture the interitence relationship (offset, etc) between
two class nodes. The 'method' should probably be augmented to include
vtable slot index info. Inh
Hi,
I guess I understand you now about the offsets. I do not need to update token,
right? Here is updated and somewhat more complette patch (now I can get list
of possible targets and use it to prune the callgraph)
I also added sanity check that ipa-cp devirtualization actually picks one
of targe
> > 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
> 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
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
Hi,
this patch represents bare bones of what I hope to give me possible targets
of a virtual call.
I basically added One Definition Rule based hash that unify all types that
are same in C++ sense (with LTO many of those are still not merged - I hope
that with few dumps I can improve the merging, t
16 matches
Mail list logo
