forked from OSchip/llvm-project
da34247a6a
The basic idea behind this patch is that since in strict aliasing mode all accesses to union members require their outermost enclosing union objects to be specified explicitly, then for a couple given accesses to union members of the form p->a.b.c... q->x.y.z... it is known they can only alias if both p and q point to the same union type and offset ranges of members a.b.c... and x.y.z... overlap. Note that the actual types of the members do not matter. Specifically, in this patch we do the following: * Make unions to be valid TBAA base access types. This enables generation of TBAA type descriptors for unions. * Encode union types as structures with a single member of a special "union member" type. Currently we do not encode information about sizes of types, but conceptually such union members are considered to be of the size of the whole union. * Encode accesses to direct and indirect union members, including member arrays, as accesses to these special members. All accesses to members of a union thus get the same offset, which is the offset of the union they are part of. This means the existing LLVM TBAA machinery is able to handle such accesses with no changes. While this is already an improvement comparing to the current situation, that is, representing all union accesses as may-alias ones, there are further changes planned to complete the support for unions. One of them is storing information about access sizes so we can distinct accesses to non-overlapping union members, including accesses to different elements of member arrays. Another change is encoding type sizes in order to make it possible to compute offsets within constant-indexed array elements. These enhancements will be addressed with separate patches. Differential Revision: https://reviews.llvm.org/D39455 llvm-svn: 319413 |
||
|---|---|---|
| .. | ||
| INPUTS | ||
| bindings | ||
| cmake | ||
| docs | ||
| examples | ||
| include | ||
| lib | ||
| runtime | ||
| test | ||
| tools | ||
| unittests | ||
| utils | ||
| www | ||
| .arcconfig | ||
| .clang-format | ||
| .clang-tidy | ||
| .gitignore | ||
| CMakeLists.txt | ||
| CODE_OWNERS.TXT | ||
| INSTALL.txt | ||
| LICENSE.TXT | ||
| ModuleInfo.txt | ||
| NOTES.txt | ||
| README.txt | ||
README.txt
//===----------------------------------------------------------------------===// // C Language Family Front-end //===----------------------------------------------------------------------===// Welcome to Clang. This is a compiler front-end for the C family of languages (C, C++, Objective-C, and Objective-C++) which is built as part of the LLVM compiler infrastructure project. Unlike many other compiler frontends, Clang is useful for a number of things beyond just compiling code: we intend for Clang to be host to a number of different source-level tools. One example of this is the Clang Static Analyzer. If you're interested in more (including how to build Clang) it is best to read the relevant web sites. Here are some pointers: Information on Clang: http://clang.llvm.org/ Building and using Clang: http://clang.llvm.org/get_started.html Clang Static Analyzer: http://clang-analyzer.llvm.org/ Information on the LLVM project: http://llvm.org/ If you have questions or comments about Clang, a great place to discuss them is on the Clang development mailing list: http://lists.llvm.org/mailman/listinfo/cfe-dev If you find a bug in Clang, please file it in the LLVM bug tracker: http://llvm.org/bugs/