GCC Middle and Back End API Reference
type_pair Struct Reference

Data Fields

tree first
tree second

Detailed Description

Basic IPA utilities for type inheritance graph construction and
   Copyright (C) 2013-2024 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

GCC is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or
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
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.

      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.

      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

      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.

      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

    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

tree type_pair::second

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