GCC Middle and Back End API Reference
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

◆ second


The documentation for this struct was generated from the following file: