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
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/>.
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
like:
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. 
