- Nov 20, 2013
-
-
Chandler Carruth authored
The FunctionPassManager is now itself a function pass. When run over a function, it runs all N of its passes over that function. This is the 1:N mapping in the pass dimension only. This allows it to be used in either a ModulePassManager or potentially some other manager that works on IR units which are supersets of Functions. This commit also adds the obvious adaptor to map from a module pass to a function pass, running the function pass across every function in the module. The test has been updated to use this new pattern. llvm-svn: 195192
-
Chandler Carruth authored
a module-specific interface. This is the first of many steps necessary to generalize the infrastructure such that we can support both a Module-to-Function and Module-to-SCC-to-Function pass manager nestings. After a *lot* of attempts that never worked and didn't even make it to a committable state, it became clear that I had gotten the layering design of analyses flat out wrong. Four days later, I think I have most of the plan for how to correct this, and I'm starting to reshape the code into it. This is just a baby step I'm afraid, but starts separating the fundamentally distinct concepts of function analysis passes and module analysis passes so that in subsequent steps we can effectively layer them, and have a consistent design for the eventual SCC layer. As part of this, I've started some interface changes to make passes more regular. The module pass accepts the module in the run method, and some of the constructor parameters are gone. I'm still working out exactly where constructor parameters vs. method parameters will be used, so I expect this to fluctuate a bit. This actually makes the invalidation less "correct" at this phase, because now function passes don't invalidate module analysis passes, but that was actually somewhat of a misfeature. It will return in a better factored form which can scale to other units of IR. The documentation has gotten less verbose and helpful. llvm-svn: 195189
-
- Nov 19, 2013
-
-
John Thompson authored
YAML I/O - Added default trait support for std:string. Making another attempt at this, this time doing a clean build on Linux, and running the LLVM, clang, and extra tests, to try to make sure there's no problems. llvm-svn: 195134
-
Michael Ilseman authored
Patch by Dmitri Shtilman! llvm-svn: 195116
-
Juergen Ributzka authored
This patch places class definitions in implementation files into anonymous namespaces to prevent weak vtables. This eliminates the need of providing an out-of-line definition to pin the vtable explicitly to the file. llvm-svn: 195092
-
Juergen Ributzka authored
This patch removes most of the trivial cases of weak vtables by pinning them to a single object file. The memory leaks in this version have been fixed. Thanks Alexey for pointing them out. Differential Revision: http://llvm-reviews.chandlerc.com/D2068 Reviewed by Andy llvm-svn: 195064
-
- Nov 18, 2013
-
-
Alexander Kornienko authored
Fixes http://llvm.org/PR16221, http://llvm.org/PR15927 Phabricator: http://llvm-reviews.chandlerc.com/D1236 Patch by Andrew Tulloch! llvm-svn: 195016
-
Alexey Samsonov authored
This change is incorrect. If you delete virtual destructor of both a base class and a subclass, then the following code: Base *foo = new Child(); delete foo; will not cause the destructor for members of Child class. As a result, I observe plently of memory leaks. Notable examples I investigated are: ObjectBuffer and ObjectBufferStream, AttributeImpl and StringSAttributeImpl. llvm-svn: 194997
-
- Nov 17, 2013
-
-
Michael Gottesman authored
[block-freq] Add BlockFrequency::scale that returns a remainder from the division and make the private scale in BlockFrequency more performant. This change is the first in a series of changes improving LLVM's Block Frequency propogation implementation to not lose probability mass in branchy code when propogating block frequency information from a basic block to its successors. This patch is a simple infrastructure improvement that does not actually modify the block frequency algorithm. The specific changes are: 1. Changes the division algorithm used when scaling block frequencies by branch probabilities to a short division algorithm. This gives us the remainder for free as well as provides a nice speed boost. When I benched the old routine and the new routine on a Sandy Bridge iMac with disabled turbo mode performing 8192 iterations on an array of length 32768, I saw ~600% increase in speed in mean/median performance. 2. Exposes a scale method that returns a remainder. This is important so we can ensure that when we scale a block frequency by some branch probability BP = N/D, the remainder from the division by D can be retrieved and propagated to other children to ensure no probability mass is lost (more to come on this). llvm-svn: 194950
-
Chandler Carruth authored
AnalysisManager. All this method did was assert something and we have a perfectly good way to trigger that assert from the query path. llvm-svn: 194947
-
- Nov 15, 2013
-
-
Juergen Ributzka authored
This patch removes most of the trivial cases of weak vtables by pinning them to a single object file. Differential Revision: http://llvm-reviews.chandlerc.com/D2068 Reviewed by Andy llvm-svn: 194865
-
Rui Ueyama authored
Summary: Make identify_magic to recognize COFF import file. Reviewers: Bigcheese CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2165 llvm-svn: 194852
-
Benjamin Kramer authored
Found by valgrind. llvm-svn: 194797
-
Matt Arsenault authored
Patch by Michele Scandale! llvm-svn: 194760
-
- Nov 14, 2013
-
-
Rui Ueyama authored
Summary: Some machine-type-neutral object files containing only undefined symbols actually do exist in the Windows standard library. Need to recognize them as COFF files. Reviewers: Bigcheese CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2164 llvm-svn: 194734
-
Nick Kledzik authored
llvm-svn: 194658
-
Nick Kledzik authored
llvm-svn: 194655
-
Nick Kledzik authored
llvm-svn: 194644
-
- Nov 13, 2013
-
-
Rui Ueyama authored
llvm-svn: 194607
-
Rui Ueyama authored
llvm-svn: 194605
-
Chandler Carruth authored
This bug only bit the C++98 build bots because all of the actual uses really do move. ;] But not *quite* ready to do the whole C++11 switch yet, so clean it up. Also add a unit test that catches this immediately. llvm-svn: 194548
-
Chandler Carruth authored
more smarts in it. This is where most of the interesting logic that used to live in the implicit-scheduling-hackery of the old pass manager will live. Like the previous commits, note that this is a very early prototype! I expect substantial changes before this is ready to use. The core of the design is the following: - We have an AnalysisManager which can be used across a series of passes over a module. - The code setting up a pass pipeline registers the analyses available with the manager. - Individual transform passes can check than an analysis manager provides the analyses they require in order to fail-fast. - There is *no* implicit registration or scheduling. - Analysis passes are different from other passes: they produce an analysis result that is cached and made available via the analysis manager. - Cached results are invalidated automatically by the pass managers. - When a transform pass requests an analysis result, either the analysis is run to produce the result or a cached result is provided. There are a few aspects of this design that I *know* will change in subsequent commits: - Currently there is no "preservation" system, that needs to be added. - All of the analysis management should move up to the analysis library. - The analysis management needs to support at least SCC passes. Maybe loop passes. Living in the analysis library will facilitate this. - Need support for analyses which are *both* module and function passes. - Need support for pro-actively running module analyses to have cached results within a function pass manager. - Need a clear design for "immutable" passes. - Need support for requesting cached results when available and not re-running the pass even if that would be necessary. - Need more thorough testing of all of this infrastructure. There are other aspects that I view as open questions I'm hoping to resolve as I iterate a bit on the infrastructure, and especially as I start writing actual passes against this. - Should we have separate management layers for function, module, and SCC analyses? I think "yes", but I'm not yet ready to switch the code. Adding SCC support will likely resolve this definitively. - How should the 'require' functionality work? Should *that* be the only way to request results to ensure that passes always require things? - How should preservation work? - Probably some other things I'm forgetting. =] Look forward to more patches in shorter order now that this is in place. llvm-svn: 194538
-
- Nov 09, 2013
-
-
Chandler Carruth authored
This is still just a skeleton. I'm trying to pull together the experimentation I've done into committable chunks, and this is the first coherent one. Others will follow in hopefully short order that move this more toward a useful initial implementation. I still expect the design to continue evolving in small ways as I work through the different requirements and features needed here though. Keep in mind, all of this is off by default. Currently, this mostly exercises the use of a polymorphic smart pointer and templates to hide the polymorphism for the pass manager from the pass implementation. The next step will be more significant, adding the first framework of analysis support. llvm-svn: 194325
-
Chandler Carruth authored
give the files a legacy prefix in the right directory. Use forwarding headers in the old locations to paper over the name change for most clients during the transitional period. No functionality changed here! This is just clearing some space to reduce renaming churn later on with a new system. Even when the new stuff starts to go in, it is going to be hidden behind a flag and off-by-default as it is still WIP and under development. This patch is specifically designed so that very little out-of-tree code has to change. I'm going to work as hard as I can to keep that the case. Only direct forward declarations of the PassManager class are impacted by this change. llvm-svn: 194324
-
Chandler Carruth authored
a derived type and this makes it *much* easier to write this code. llvm-svn: 194321
-
Chandler Carruth authored
llvm-svn: 194320
-
Chandler Carruth authored
r-value references. I still want to test that when we have them, llvm_move is actually a move. Have I mentioned that I really want to move to C++11? ;] llvm-svn: 194318
-
Chandler Carruth authored
Clang managed to never instantiate the copy constructor. Added tests to ensure this path is tested. We could still use tests for the polymorphic nature. Those coming up next. llvm-svn: 194317
-
Chandler Carruth authored
to fix C++98 builds. llvm-svn: 194316
-
Chandler Carruth authored
unique ownership smart pointer which is *deep* copyable by assuming it can call a T::clone() method to allocate a copy of the owned data. This is mostly useful with containers or other collections of uniquely owned data in C++98 where they *might* copy. With C++11 we can likely remove this in favor of move-only types and containers wrapped around those types. llvm-svn: 194315
-
Adrian Prantl authored
This would cause internal symbols that are only referenced by global initializers to be removed. This reverts commit 194219. llvm-svn: 194304
-
Adrian Prantl authored
This reverts commit 194219. llvm-svn: 194303
-
- Nov 07, 2013
-
-
Bill Wendling authored
llvm-svn: 194219
-
Bill Wendling authored
The BlockAddress doesn't have access to the correct basic blocks until the functions have been cloned. This causes the BlockAddress to point to the old values. Just wait until the functions have been cloned before copying the initializers. PR13163 llvm-svn: 194218
-
- Nov 05, 2013
-
-
Rafael Espindola authored
ErrorOr had quiet a bit of complexity and indirection to be able to hold a user type with the error. That feature is not used anymore. This patch removes it, it will live in svn history if we ever need it again. If we do need it again, IMHO there is one thing that should be done differently: Holding extra info in the error is not a property a function also returning a value or not. The ability to hold extra info should be in the error type and ErrorOr templated over it so that we don't need the funny looking ErrorOr<void>. llvm-svn: 194030
-
- Oct 31, 2013
-
-
Rafael Espindola authored
llvm-svn: 193734
-
- Oct 30, 2013
-
-
Rafael Espindola authored
The function verifyFunction() in lib/IR/Verifier.cpp misses some calls. It creates a temporary FunctionPassManager that will run a single Verifier pass. Unfortunately, FunctionPassManager is no PassManager and does not call doInitialization() and doFinalization() by itself. Verifier does important tasks in doInitialization() such as collecting type information used to check DebugInfo metadata and doFinalization() does some additional checks. Therefore these checks were missed and debug info couldn't be verified at all, it just crashed if the function had some. verifyFunction() is currently not used in llvm unless -debug option is enabled, and in unittests/IR/VerifierTest.cpp VerifierTest had to be changed to create the function in a module from which the type debug info can be collected. Patch by Michael Kruse. llvm-svn: 193719
-
Rui Ueyama authored
startswith_lower is ocassionally useful and I think worth adding. endwith_lower is added for completeness. Differential Revision: http://llvm-reviews.chandlerc.com/D2041 llvm-svn: 193706
-
Nuno Lopes authored
the case [x, INT_MIN) was not handled optimally llvm-svn: 193694
-
- Oct 29, 2013
-
-
Alexey Samsonov authored
Based on D2050 by Timur Iskhodzhanov. llvm-svn: 193619
-