Chandler Carruth 90665f11d7 [PM] Port the always inliner to the new pass manager in a much more ... minimal and boring form than the old pass manager's version. This pass does the very minimal amount of work necessary to inline functions declared as always-inline. It doesn't support a wide array of things that the legacy pass manager did support, but is alse ... about 20 lines of code. So it has that going for it. Notably things this doesn't support: - Array alloca merging - To support the above, bottom-up inlining with careful history tracking and call graph updates - DCE of the functions that become dead after this inlining. - Inlining through call instructions with the always_inline attribute. Instead, it focuses on inlining functions with that attribute. The first I've omitted because I'm hoping to just turn it off for the primary pass manager. If that doesn't pan out, I can add it here but it will be reasonably expensive to do so. The second should really be handled by running global-dce after the inliner. I don't want to re-implement the non-trivial logic necessary to do comdat-correct DCE of functions. This means the -O0 pipeline will have to be at least 'always-inline,global-dce', but that seems reasonable to me. If others are seriously worried about this I'd like to hear about it and understand why. Again, this is all solveable by factoring that logic into a utility and calling it here, but I'd like to wait to do that until there is a clear reason why the existing pass-based factoring won't work. The final point is a serious one. I can fairly easily add support for this, but it seems both costly and a confusing construct for the use case of the always inliner running at -O0. This attribute can of course still impact the normal inliner easily (although I find that a questionable re-use of the same attribute). I've started a discussion to sort out what semantics we want here and based on that can figure out if it makes sense ta have this complexity at O0 or not. One other advantage of this design is that it should be quite a bit faster due to checking for whether the function is a viable candidate for inlining exactly once per function instead of doing it for each call site. Anyways, hopefully a reasonable starting point for this pass. Differential Revision: https://reviews.llvm.org/D23299 llvm-svn: 278896		2016-08-17 02:56:20 +00:00
..
BugDriver.cpp	Change linkInModule to take a std::unique_ptr.	2015-12-16 23:16:33 +00:00
BugDriver.h	[bugpoint] Delete a stale comment.	2016-06-29 03:02:01 +00:00
bugpoint.cpp	[PM] Port the always inliner to the new pass manager in a much more	2016-08-17 02:56:20 +00:00
CMakeLists.txt
CrashDebugger.cpp	Use the range variant of find instead of unpacking begin/end	2016-08-11 22:21:41 +00:00
ExecutionDriver.cpp	Apply most suggestions of clang-tidy's performance-unnecessary-value-param	2016-06-08 19:09:22 +00:00
ExtractFunction.cpp	[bugpoint] Simplify code by moving exception to only caller	2016-06-29 00:26:21 +00:00
FindBugs.cpp
ListReducer.h
LLVMBuild.txt
Miscompilation.cpp	[bugpoint] Simplify code by moving exception to only caller	2016-06-29 00:26:21 +00:00
OptimizerDriver.cpp	[bugpoint] Simplify code by moving exception to only caller	2016-06-29 00:26:21 +00:00
ToolRunner.cpp	Apply clang-tidy's misc-move-constructor-init throughout LLVM.	2016-05-27 14:27:24 +00:00
ToolRunner.h	[Bugpoint] Use 'CC' instead of 'GCC' for variable naming.	2015-10-14 20:29:54 +00:00