GCC Middle and Back End API Reference
alias_set_hash Struct Reference
Inheritance diagram for alias_set_hash:
Collaboration diagram for alias_set_hash:

Public Types

typedef int value_type
typedef int compare_type

Static Public Member Functions

static void mark_deleted (int &)
static void mark_empty (int &)
static bool is_deleted (int)
static bool is_empty (int)
static hashval_t hash (value_type)
static bool equal (value_type existing, value_type candidate)
static void remove (Type &)

Static Public Attributes

static const bool empty_zero_p

Detailed Description

Alias analysis for GNU C
   Copyright (C) 1997-2024 Free Software Foundation, Inc.
   Contributed by John Carr (jfc@mit.edu).

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
The aliasing API provided here solves related but different problems:

  Say there exists (in c)

  struct X {
    struct Y y1;
    struct Z z2;
  } x1, *px1,  *px2;

  struct Y y2, *py;
  struct Z z2, *pz;

  py = &x1.y1;
  px2 = &x1;

  Consider the four questions:

  Can a store to x1 interfere with px2->y1?
  Can a store to x1 interfere with px2->z2?
  Can a store to x1 change the value pointed to by with py?
  Can a store to x1 change the value pointed to by with pz?

  The answer to these questions can be yes, yes, yes, and maybe.

  The first two questions can be answered with a simple examination
  of the type system.  If structure X contains a field of type Y then
  a store through a pointer to an X can overwrite any field that is
  contained (recursively) in an X (unless we know that px1 != px2).

  The last two questions can be solved in the same way as the first
  two questions but this is too conservative.  The observation is
  that in some cases we can know which (if any) fields are addressed
  and if those addresses are used in bad ways.  This analysis may be
  language specific.  In C, arbitrary operations may be applied to
  pointers.  However, there is some indication that this may be too
  conservative for some C++ types.

  The pass ipa-type-escape does this analysis for the types whose
  instances do not escape across the compilation boundary.

  Historically in GCC, these two problems were combined and a single
  data structure that was used to represent the solution to these
  problems.  We now have two similar but different data structures,
  The data structure to solve the last two questions is similar to
  the first, but does not contain the fields whose address are never
  taken.  For types that do escape the compilation unit, the data
  structures will have identical information.
The alias sets assigned to MEMs assist the back-end in determining
which MEMs can alias which other MEMs.  In general, two MEMs in
different alias sets cannot alias each other, with one important
exception.  Consider something like:

  struct S { int i; double d; };

a store to an `S' can alias something of either type `int' or type
`double'.  (However, a store to an `int' cannot alias a `double'
and vice versa.)  We indicate this via a tree structure that looks
        struct S
         /   \
        /     \
      |/_     _\|
      int    double

(The arrows are directed and point downwards.)
 In this situation we say the alias set for `struct S' is the
`superset' and that those for `int' and `double' are `subsets'.

To see whether two alias sets can point to the same memory, we must
see if either alias set is a subset of the other. We need not trace
past immediate descendants, however, since we propagate all
grandchildren up one level.

Alias set zero is implicitly a superset of all other alias sets.
However, this is no actual entry for alias set zero.  It is an
error to attempt to explicitly construct a subset of zero.   

Member Typedef Documentation

◆ compare_type

typedef int int_hash< int , Empty, Deleted >::compare_type

◆ value_type

typedef int int_hash< int , Empty, Deleted >::value_type

Member Function Documentation

◆ equal()

template<typename Type >
bool int_hash_base< Type >::equal ( value_type existing,
value_type candidate )

References y.

◆ hash()

template<typename Type >
hashval_t int_hash_base< Type >::hash ( value_type x)

◆ is_deleted()

bool int_hash< int , Empty, Deleted >::is_deleted ( int x)

◆ is_empty()

bool int_hash< int , Empty, Deleted >::is_empty ( int x)

◆ mark_deleted()

void int_hash< int , Empty, Deleted >::mark_deleted ( int & x)

◆ mark_empty()

void int_hash< int , Empty, Deleted >::mark_empty ( int & x)

◆ remove()

template<typename Type >
void typed_noop_remove< Type >::remove ( Type & )
Remove doing nothing.   

Field Documentation

◆ empty_zero_p

const bool int_hash< int , Empty, Deleted >::empty_zero_p

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