- Generated by
1.8.1.1
|
GCC Middle and Back End API Reference
|
Data Structures | |
| struct | odr_type_d |
| struct | odr_hasher |
| struct | polymorphic_call_target_d |
| struct | polymorphic_call_target_hasher |
Typedefs | |
| typedef hash_table< odr_hasher > | odr_hash_type |
| typedef hash_table < polymorphic_call_target_hasher > | polymorphic_call_target_hash_type |
Variables | |
| static pointer_set_t * | cached_polymorphic_call_targets |
| static odr_hash_type | odr_hash |
| static vec< odr_type, va_gc > * | odr_types_ptr |
| static polymorphic_call_target_hash_type | polymorphic_call_target_hash |
| typedef hash_table<odr_hasher> odr_hash_type |
ODR type hash used to lookup ODR type based on tree type node.
Polymorphic call target query cache.
|
static |
TYPE is equivalent to VAL by ODR, but its tree representation differs from VAL->type. This may happen in LTO where tree merging did not merge all variants of the same type. It may or may not mean the ODR violation. Add it to the list of duplicates and warn on some violations.
See if this duplicate is new.
First we compare memory layout.
Next sanity check that bases are the same. If not, we will end
up producing wrong answers. Regularize things a little. During LTO same types may come with
different BINFOs. Either because their virtual table was
not merged by tree merging and only later at decl merging or
because one type comes with external vtable, while other
with internal. We want to merge equivalent binfos to conserve
memory and streaming overhead.
The external vtables are more harmful: they contain references
to external declarations of methods that may be defined in the
merged LTO unit. For this reason we absolutely need to remove
them and replace by internal variants. Not doing so will lead
to incomplete answers from possible_polymorphic_call_targets.
| void build_type_inheritance_graph | ( | void | ) |
Initialize IPA devirt and build inheritance tree graph.
We reconstruct the graph starting of types of all methods seen in the
the unit.
References pointer_set_insert().
|
static |
When virtual function is removed, we may need to flush the cache.
References hash_table< Descriptor, Allocator >::create(), pointer_set_create(), and polymorphic_call_target_hash.
Referenced by devirt_variable_node_removal_hook().
|
static |
When virtual table is removed, we may need to flush the cache.
References cgraph_add_node_removal_hook(), devirt_node_removal_hook(), and varpool_add_node_removal_hook().
|
static |
Dump ODR type T and all its derrived type. INDENT specify indentation for recusive printing.
| void dump_possible_polymorphic_call_targets | ( | FILE * | f, |
| tree | otr_type, | ||
| HOST_WIDE_INT | otr_token | ||
| ) |
Dump all possible targets of a polymorphic call.
References flags_from_decl_or_type(), lookup_attribute(), and NODE_FREQUENCY_NORMAL.
Referenced by varpool_finalize_decl().
|
static |
Dump the type inheritance graph.
|
static |
Destroy polymorphic call target query cache.
|
static |
Gate for IPCP optimization.
| odr_type get_odr_type | ( | ) |
Get ODR type hash entry for TYPE. If INSERT is true, create possibly new entry.
See if we already have entry for type.
With LTO we need to support multiple tree representation of
the same ODR type. For now record only polymorphic types. other are
pointless for devirtualization and we can not precisely
determine ODR equivalency of these during LTO. First record bases, then add into array so ids are increasing.
| hashval_t hash_type_name | ( | ) |
Produce hash based on type name.
If not in LTO, all main variants are unique, so we can do
pointer hash. Anonymous types are unique.
For polymorphic types, we can simply hash the virtual table.
Rest is not implemented yet.
References iterative_hash_hashval_t().
|
static |
The ipa-devirt pass. When polymorphic call has only one likely target in the unit, turn it into speculative call.
When dumping see if we agree with speculation.
This is reached only when dumping; check if we agree or disagree
with the speculation. Do not introduce new references to external symbols. While we
can handle these just well, it is common for programs to
incorrectly with headers defining methods they are linked
with.
| bool likely_target_p | ( | ) |
Return true if N looks like likely target of a polymorphic call. Rule out cxa_pure_virtual, noreturns, function declared cold and other obvious cases.
cxa_pure_virtual and similar things are not likely.
| ipa_opt_pass_d* make_pass_ipa_devirt | ( | ) |
|
static |
If TARGET has associated node, record it in the NODES array.
Those are used to mark impossible scenarios.
References symtab_node_base::definition, gimple_get_virt_method_for_binfo(), pointer_set_insert(), polymorphic_type_binfo_p(), record_binfo(), types_same_for_odr(), and varpool_get_node().
| tree method_class_type | ( | ) |
Given method type T, return type of class it belongs to. Lookup this pointer and get its type.
Referenced by varpool_finalize_decl(), and walk_polymorphic_call_targets().
|
inlinestatic |
Return true if BINFO corresponds to a type with virtual methods. Every type has several BINFOs. One is the BINFO associated by the type while other represents bases of derived types. The BINFOs representing bases do not have BINFO_VTABLE pointer set when this is the single inheritance (because vtables are shared). Look up the BINFO of type and check presence of its vtable.
See if BINFO's type has an virtual table associtated with it.
Referenced by maybe_record_node().
| bool possible_polymorphic_call_target_p | ( | tree | otr_type, |
| HOST_WIDE_INT | otr_token, | ||
| struct cgraph_node * | n | ||
| ) |
Return true if N can be possibly target of a polymorphic call of OTR_TYPE/OTR_TOKEN.
At a moment we allow middle end to dig out new external declarations
as a targets of polymorphic calls.
References cgraph_node_name(), dump_file, cgraph_node::indirect_calls, cgraph_edge::indirect_info, cgraph_edge::next_callee, symtab_node_base::order, pointer_set_create(), and cgraph_indirect_call_info::polymorphic.
Referenced by dump_possible_polymorphic_call_targets(), and possible_polymorphic_call_target_p().
| vec<cgraph_node *> possible_polymorphic_call_targets | ( | tree | otr_type, |
| HOST_WIDE_INT | otr_token, | ||
| bool * | finalp, | ||
| void ** | cache_token | ||
| ) |
Return vector containing possible targets of polymorphic call of type OTR_TYPE caling method OTR_TOKEN with OFFSET. If FINALp is non-NULL, store true if the list is complette. CACHE_TOKEN (if non-NULL) will get stored to an unique ID of entry in the target cache. If user needs to visit every target list just once, it can memoize them. Returned vector is placed into cache. It is NOT caller's responsibility to free it. The vector can be freed on cgraph_remove_node call if the particular node is a virtual function present in the cache.
If we do not have type in our hash it means we never seen any method
in it. For anonymous namespace types we can attempt to build full type.
All derivations must be in this unit. Initialize query cache.
Lookup cached answer.
Do actual search.
First see virtual method of type itself.
TODO: If method is final, we can stop here and signaize that
list is final. We need C++ FE to pass our info about final
methods and classes. Walk recursively all derived types. Here we need to lookup proper basetype
via their BINFO walk that is done by record_binfo
|
static |
Lookup virtual methods matching OTR_TYPE (with OFFSET and OTR_TOKEN) of TYPE, insert them to NODES, recurse into derived nodes. INSERTED is used to avoid duplicate insertions of methods into NODES. MATCHED_VTABLES are used to avoid duplicate walking vtables.
References iterative_hash_hashval_t().
|
static |
See if BINFO's type match OTR_TYPE. If so, lookup method in vtable of TYPE_BINFO and insert method to NODES array. Otherwise recurse to base BINFOs. This match what get_binfo_at_offset does, but with offset being unknown. TYPE_BINFO is binfo holding an virtual table matching BINFO's type. In the case of single inheritance, this is binfo of BINFO's type ancestor (vtable is shared), otherwise it is binfo of BINFO's type. MATCHED_VTABLES tracks virtual tables we already did lookup for virtual function in. ANONYMOUS is true if BINFO is part of anonymous namespace.
For types in anonymous namespace first check if the respective vtable
is alive. If not, we know the type can't be called. Walk bases.
Walking bases that have no virtual method is pointless excercise.
In the case of single inheritance, the virtual table
is shared with the outer type.
Referenced by maybe_record_node().
| void update_type_inheritance_graph | ( | void | ) |
After callgraph construction new external nodes may appear. Add them into the graph.
We reconstruct the graph starting of types of all methods seen in the
the unit.
|
static |
@verbatim
Basic IPA utilities for type inheritance graph construction and devirtualization. Copyright (C) 2013 Free Software Foundation, Inc. Contributed by Jan Hubicka
This file is part of GCC.
GCC is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3, or (at your option) any later version.
GCC is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with GCC; see the file COPYING3. If not see http://www.gnu.org/licenses/.
Brief vocalburary:
ODR = One Definition Rule
In short, the ODR states that:
1 In any translation unit, a template, type, function, or object can
have no more than one definition. Some of these can have any number
of declarations. A definition provides an instance.
2 In the entire program, an object or non-inline function cannot have
more than one definition; if an object or function is used, it must
have exactly one definition. You can declare an object or function
that is never used, in which case you don't have to provide
a definition. In no event can there be more than one definition.
3 Some things, like types, templates, and extern inline functions, can
be defined in more than one translation unit. For a given entity,
each definition must be the same. Non-extern objects and functions
in different translation units are different entities, even if their
names and types are the same.
OTR = OBJ_TYPE_REF
This is the Gimple representation of type information of a polymorphic call.
It contains two parameters:
otr_type is a type of class whose method is called.
otr_token is the index into virtual table where address is taken.
BINFO
This is the type inheritance information attached to each tree
RECORD_TYPE by the C++ frotend. It provides information about base
types and virtual tables.
BINFO is linked to the RECORD_TYPE by TYPE_BINFO.
BINFO also links to its type by BINFO_TYPE and to the virtual table by
BINFO_VTABLE.
Base types of a given type are enumerated by BINFO_BASE_BINFO
vector. Members of this vectors are not BINFOs associated
with a base type. Rather they are new copies of BINFOs
(base BINFOs). Their virtual tables may differ from
virtual table of the base type. Also BINFO_OFFSET specifies
offset of the base within the type.
In the case of single inheritance, the virtual table is shared
and BINFO_VTABLE of base BINFO is NULL. In the case of multiple
inheritance the individual virtual tables are pointer to by
BINFO_VTABLE of base binfos (that differs of BINFO_VTABLE of
binfo associated to the base type).
BINFO lookup for a given base type and offset can be done by
get_binfo_at_offset. It returns proper BINFO whose virtual table
can be used for lookup of virtual methods associated with the
base type.
token
This is an index of virtual method in virtual table associated
to the type defining it. Token can be looked up from OBJ_TYPE_REF
or from DECL_VINDEX of a given virtual table.
polymorphic (indirect) call
This is callgraph represention of virtual method call. Every
polymorphic call contains otr_type and otr_token taken from
original OBJ_TYPE_REF at callgraph construction time.
What we do here:
build_type_inheritance_graph triggers a construction of the type inheritance
graph.
We reconstruct it based on types of methods we see in the unit.
This means that the graph is not complete. Types with no methods are not
inserted into the graph. Also types without virtual methods are not
represented at all, though it may be easy to add this.
The inheritance graph is represented as follows:
Vertices are structures odr_type. Every odr_type may correspond
to one or more tree type nodes that are equivalent by ODR rule.
(the multiple type nodes appear only with linktime optimization)
Edges are represented by odr_type->base and odr_type->derived_types.
At the moment we do not track offsets of types for multiple inheritance.
Adding this is easy.
possible_polymorphic_call_targets returns, given an parameters found in
indirect polymorphic edge all possible polymorphic call targets of the call.
pass_ipa_devirt performs simple speculative devirtualization.
Pointer set of all call targets appearing in the cache.
|
static |
ODR types are also stored into ODR_TYPE vector to allow consistent walking. Bases appear before derived types. Vector is garbage collected so we won't end up visiting empty types.
|
static |
Referenced by devirt_node_removal_hook().
1.8.1.1