forked from OSchip/llvm-project
3eaa53e805
Relative to the original commit, this fixes some warnings, and is based on the deletion of the IRBuilder copy constructor in D74693. The automatic copy constructor would no longer be safe. ----- Related llvm-dev thread: http://lists.llvm.org/pipermail/llvm-dev/2020-February/138951.html This patch moves the IRBuilder from templating over the constant folder and inserter towards making both of these virtual. There are a couple of motivations for this: 1. It's not possible to share code between use-sites that use different IRBuilder folders/inserters (short of templating the code and moving it into headers). 2. Methods currently defined on IRBuilderBase (which is not templated) do not use the custom inserter, resulting in subtle bugs (e.g. incorrect InstCombine worklist management). It would be possible to move those into the templated IRBuilder, but... 3. The vast majority of the IRBuilder implementation has to live in the header, because it depends on the template arguments. 4. We have many unnecessary dependencies on IRBuilder.h, because it is not easy to forward-declare. (Significant parts of the backend depend on it via TargetLowering.h, for example.) This patch addresses the issue by making the following changes: * IRBuilderDefaultInserter::InsertHelper becomes virtual. IRBuilderBase accepts a reference to it. * IRBuilderFolder is introduced as a virtual base class. It is implemented by ConstantFolder (default), NoFolder and TargetFolder. IRBuilderBase has a reference to this as well. * All the logic is moved from IRBuilder to IRBuilderBase. This means that methods can in the future replace their IRBuilder<> & uses (or other specific IRBuilder types) with IRBuilderBase & and thus be usable with different IRBuilders. * The IRBuilder class is now a thin wrapper around IRBuilderBase. Essentially it only stores the folder and inserter and takes care of constructing the base builder. What this patch doesn't do, but should be simple followups after this change: * Fixing use of the inserter for creation methods originally defined on IRBuilderBase. * Replacing IRBuilder<> uses in arguments with IRBuilderBase, where useful. * Moving code from the IRBuilder header to the source file. From the user perspective, these changes should be mostly transparent: The only thing that consumers using a custom inserted may need to do is inherit from IRBuilderDefaultInserter publicly and mark their InsertHelper as public. Differential Revision: https://reviews.llvm.org/D73835 |
||
|---|---|---|
| .. | ||
| cmake | ||
| docs | ||
| include/polly | ||
| lib | ||
| test | ||
| tools | ||
| unittests | ||
| utils | ||
| www | ||
| .arcconfig | ||
| .arclint | ||
| .gitattributes | ||
| .gitignore | ||
| CMakeLists.txt | ||
| CREDITS.txt | ||
| LICENSE.txt | ||
| README | ||
README
Polly - Polyhedral optimizations for LLVM ----------------------------------------- http://polly.llvm.org/ Polly uses a mathematical representation, the polyhedral model, to represent and transform loops and other control flow structures. Using an abstract representation it is possible to reason about transformations in a more general way and to use highly optimized linear programming libraries to figure out the optimal loop structure. These transformations can be used to do constant propagation through arrays, remove dead loop iterations, optimize loops for cache locality, optimize arrays, apply advanced automatic parallelization, drive vectorization, or they can be used to do software pipelining.