GCC Middle and Back End API Reference
|
Data Fields | |
alias_set_type | alias_set |
int | has_zero_child |
splay_tree | children |
@verbatim Alias analysis for GNU C
Copyright (C) 1997-2013 Free Software Foundation, Inc. Contributed by John Carr (jfc@m). it.e du
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.
alias_set_type alias_set_entry_d::alias_set |
Referenced by record_alias_subset().
splay_tree alias_set_entry_d::children |
Referenced by alias_set_subset_of(), alias_sets_conflict_p(), and record_alias_subset().
int alias_set_entry_d::has_zero_child |
Referenced by alias_set_subset_of(), alias_sets_conflict_p(), and record_alias_subset().