type_pair Struct Reference
Inheritance diagram for type_pair:
Data Fields | |
| tree | first |
| tree | second |
Detailed Description
Basic IPA utilities for type inheritance graph construction and devirtualization. Copyright (C) 2013-2025 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 vocabulary:
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++ frontend. 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 representation 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.
Hash based set of pairs of types.
Field Documentation
◆ first
| tree type_pair::first |
◆ second
| tree type_pair::second |
Referenced by default_hash_traits< type_pair >::hash(), and type_pair_strictly_matches_mode_p().
The documentation for this struct was generated from the following file:
