summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR
Commit message (Collapse)AuthorAgeFilesLines
* Fix spurious return introduced by my earlier patch to DebugInfoRenato Golin2013-11-261-1/+0
| | | | llvm-svn: 195775
* Add return to DIType::VerifyRenato Golin2013-11-261-3/+3
| | | | | | | | Code scanner ran by Sylvestre Ledru got a no_return bug in DebugInfo.cpp. Adding the return statements that should be there. llvm-svn: 195772
* [PM] Factor the overwhelming majority of the interface boiler plate outChandler Carruth2013-11-261-49/+42
| | | | | | | | | | | | | | of the two analysis managers into a CRTP base class that can be shared and re-used in building any analysis manager. This will in turn simplify adding yet another analysis manager to the system. The base class provides all of the interface sugar for the analysis manager delegating the functionality back through DerivedT methods which operate on simple pass IDs. It also provides the pass registration, storage, and lookup system which is common across the various formulations of analysis managers. llvm-svn: 195747
* [PM] Complete the cross-layer interfaces with a Module-to-FunctionChandler Carruth2013-11-231-0/+2
| | | | | | | | | | | | | proxy. This lets a function pass query a module analysis manager. However, the interface is const to indicate that only cached results can be safely queried. With this, I think the new pass manager is largely functionally complete for modules and analyses. Still lots to test, and need to generalize to SCCs and Loops, and need to build an adaptor layer to support the use of existing Pass objects in the new managers. llvm-svn: 195538
* [PM] Add support to the analysis managers to query explicitly for cachedChandler Carruth2013-11-231-0/+13
| | | | | | | | | | | results. This is the last piece of infrastructure needed to effectively support querying *up* the analysis layers. The next step will be to introduce a proxy which provides access to those layers with appropriate use of const to direct queries to the safe interface. llvm-svn: 195525
* [PM] Switch the downward invalidation to be incremental where only theChandler Carruth2013-11-221-11/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | one function's analyses are invalidated at a time. Also switch the preservation of the proxy to *fully* preserve the lower (function) analyses. Combined, this gets both upward and downward analysis invalidation to a point I'm happy with: - A function pass invalidates its function analyses, and its parent's module analyses. - A module pass invalidates all of its functions' analyses including the set of which functions are in the module. - A function pass can preserve a module analysis pass. - If all function passes preserve a module analysis pass, that preservation persists. If any doesn't the module analysis is invalidated. - A module pass can opt into managing *all* function analysis invalidation itself or *none*. - The conservative default is none, and the proxy takes the maximally conservative approach that works even if the set of functions has changed. - If a module pass opts into managing function analysis invalidation it has to propagate the invalidation itself, the proxy just does nothing. The only thing really missing is a way to query for a cached analysis or nothing at all. With this, function passes can more safely request a cached module analysis pass without fear of it accidentally running part way through. llvm-svn: 195519
* Debug Info: move StripDebugInfo from StripSymbols.cpp to DebugInfo.cpp.Manman Ren2013-11-221-0/+52
| | | | | | | | | | We can share the implementation between StripSymbols and dropping debug info for metadata versions that do not match. Also update the comments to match the implementation. A follow-on patch will drop the "Debug Info Version" module flag in StripDebugInfo. llvm-svn: 195505
* [PM] Teach the analysis managers to pass themselves as arguments to theChandler Carruth2013-11-221-2/+2
| | | | | | | | | | | | | | run methods of the analysis passes. Also generalizes and re-uses the SFINAE for transformation passes so that users can write an analysis pass and only accept an analysis manager if that is useful to their pass. This completes the plumbing to make an analysis manager available through every pass's run method if desired so that passes no longer need to be constructed around them. llvm-svn: 195451
* [PM] Fix the analysis templates' usage of IRUnitT.Chandler Carruth2013-11-221-3/+3
| | | | | | | | | | | This is supposed to be the whole type of the IR unit, and so we shouldn't pass a pointer to it but rather the value itself. In turn, we need to provide a 'Module *' as that type argument (for example). This will become more relevant with SCCs or other units which may not be passed as a pointer type, but also brings consistency with the transformation pass templates. llvm-svn: 195445
* [PM] Switch analysis managers to be threaded through the run methodsChandler Carruth2013-11-221-9/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | rather than the constructors of passes. This simplifies the APIs of passes significantly and removes an error prone pattern where the *same* manager had to be given to every different layer. With the new API the analysis managers themselves will have to be cross connected with proxy analyses that allow a pass at one layer to query for the analysis manager of another layer. The proxy will both expose a handle to the other layer's manager and it will provide the invalidation hooks to ensure things remain consistent across layers. Finally, the outer-most analysis manager has to be passed to the run method of the outer-most pass manager. The rest of the propagation is automatic. I've used SFINAE again to allow passes to completely disregard the analysis manager if they don't need or want to care. This helps keep simple things simple for users of the new pass manager. Also, the system specifically supports passing a null pointer into the outer-most run method if your pass pipeline neither needs nor wants to deal with analyses. I find this of dubious utility as while some *passes* don't care about analysis, I'm not sure there are any real-world users of the pass manager itself that need to avoid even creating an analysis manager. But it is easy to support, so there we go. Finally I renamed the module proxy for the function analysis manager to the more verbose but less confusing name of FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea what else to name these things. I'm expecting in the fullness of time to potentially have the complete cross product of types at the proxy layer: {Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy (except for XAnalysisManagerXProxy which doesn't make any sense) This should make it somewhat easier to do the next phases which is to build the upward proxy and get its invalidation correct, as well as to make the invalidation within the Module -> Function mapping pass be more fine grained so as to invalidate fewer fuction analyses. After all of the proxy analyses are done and the invalidation working, I'll finally be able to start working on the next two fun fronts: how to adapt an existing pass to work in both the legacy pass world and the new one, and building the SCC, Loop, and Region counterparts. Fun times! llvm-svn: 195400
* [PM] Widen the interface for invalidate on an analysis result now thatChandler Carruth2013-11-211-7/+15
| | | | | | | | | | | | | | | | | | | it is completely optional, and sink the logic for handling the preserved analysis set into it. This allows us to implement the delegation logic desired in the proxy module analysis for the function analysis manager where if the proxy itself is preserved we assume the set of functions hasn't changed and we do a fine grained invalidation by walking the functions in the module and running the invalidate for them all at the manager level and letting it try to invalidate any passes. This in turn makes it blindingly obvious why we should hoist the invalidate trait and have two collections of results. That allows handling invalidation for almost all analyses without indirect calls and it allows short circuiting when the preserved set is all. llvm-svn: 195338
* llvm-cov: Formatting change.Yuchen Wu2013-11-211-2/+1
| | | | llvm-svn: 195310
* [PM] Add a module analysis pass proxy for the function analysis manager.Chandler Carruth2013-11-211-0/+37
| | | | | | | | | | | | | | | | This proxy will fill the role of proxying invalidation events down IR unit layers so that when a module changes we correctly invalidate function analyses. Currently this is a very coarse solution -- any change blows away the entire thing -- but the next step is to make invalidation handling more nuanced so that we can propagate specific amounts of invalidation from one layer to the next. The test is extended to place a module pass between two function pass managers each of which have preserved function analyses which get correctly invalidated by the module pass that might have changed what functions are even in the module. llvm-svn: 195304
* [PM] Add the preservation system to the new pass manager.Chandler Carruth2013-11-201-18/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a new set-like type which represents a set of preserved analysis passes. The set is managed via the opaque PassT::ID() void*s. The expected convenience templates for interacting with specific passes are provided. It also supports a symbolic "all" state which is represented by an invalid pointer in the set. This state is nicely saturating as it comes up often. Finally, it supports intersection which is used when finding the set of preserved passes after N different transforms. The pass API is then changed to return the preserved set rather than a bool. This is much more self-documenting than the previous system. Returning "none" is a conservatively correct solution just like returning "true" from todays passes and not marking any passes as preserved. Passes can also be dynamically preserved or not throughout the run of the pass, and whatever gets returned is the binding state. Finally, preserving "all" the passes is allowed for no-op transforms that simply can't harm such things. Finally, the analysis managers are changed to instead of blindly invalidating all of the analyses, invalidate those which were not preserved. This should rig up all of the basic preservation functionality. This also correctly combines the preservation moving up from one IR-layer to the another and the preservation aggregation across N pass runs. Still to go is incrementally correct invalidation and preservation across IR layers incrementally during N pass runs. That will wait until we have a device for even exposing analyses across IR layers. While the core of this change is obvious, I'm not happy with the current testing, so will improve it to cover at least some of the invalidation that I can test easily in a subsequent commit. llvm-svn: 195241
* [PM] Make the function pass manager more regular.Chandler Carruth2013-11-201-8/+7
| | | | | | | | | | | | | | | | 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
* llvm-cov: Added file checksum to gcno and gcda files.Yuchen Wu2013-11-201-0/+7
| | | | | | | | | | | | Instead of permanently outputting "MVLL" as the file checksum, clang will create gcno and gcda checksums by hashing the destination block numbers of every arc. This allows for llvm-cov to check if the two gcov files are synchronized. Regenerated the test files so they contain the checksum. Also added negative test to ensure error when the checksums don't match. llvm-svn: 195191
* [PM] Split the analysis manager into a function-specific interface andChandler Carruth2013-11-201-85/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Expose the fence instruction via the C API.Filip Pizlo2013-11-201-15/+24
| | | | llvm-svn: 195173
* Make it explicit that nulls are not allowed in names.Rafael Espindola2013-11-191-0/+2
| | | | | | | | | | The object files we support use null terminated strings, so there is no way to support these. This patch adds an assert to catch bad API use and an error check in the .ll parser. llvm-svn: 195155
* llvm-cov: Moved printing after error checks.Yuchen Wu2013-11-191-6/+8
| | | | llvm-svn: 195153
* llvm-cov: Added constness property to methods.Yuchen Wu2013-11-191-14/+15
| | | | | | | Added constness to methods that shouldn't modify objects. Replaced operator[] lookup in maps with find() instead. llvm-svn: 195151
* DataLayout: value initialize globals to avoid static construction.Benjamin Kramer2013-11-191-2/+2
| | | | llvm-svn: 195150
* [weak vtables] Remove a bunch of weak vtablesJuergen Ributzka2013-11-194-7/+12
| | | | | | | | | | | | 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
* DebugInfo: Simplify a few more explicit constructions, underconstrained ↵David Blaikie2013-11-181-4/+4
| | | | | | types, and make DIType(MDNode*) explicit like all the other DI* node ctors. llvm-svn: 195055
* The 'optnone' attribute means don't inline anything into this functionPaul Robinson2013-11-181-3/+3
| | | | | | | | | | (except functions marked always_inline). Functions with 'optnone' must also have 'noinline' so they don't get inlined into any other function. Based on work by Andrea Di Biagio. llvm-svn: 195046
* Revert r194865 and r194874.Alexey Samsonov2013-11-184-5/+11
| | | | | | | | | | | | 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
* Debug Info Verifier: disable it by default.Manman Ren2013-11-181-1/+1
| | | | | | | | | | | | | | Debug info verifier is part of the verifier which is a Function Pass. Tot currently tries to pull all reachable debug info MDNodes in each function, which is too time-consuming. The correct fix seems to be separating debug info verification to its own module pass. I will disable the debug info verifier until a correct fix is found. For Bill's testing case, enabling debug info verifier increase compile time from 11s to 11m. llvm-svn: 194986
* Debug Info: fix typo in function name.Manman Ren2013-11-171-5/+5
| | | | llvm-svn: 194975
* Debug Info Verifier: fix when to find debug info nodes and when to verify them.Manman Ren2013-11-171-5/+11
| | | | | | | | | | | | | | | | | | We used to collect debug info MDNodes in doInitialization and verify them in doFinalization. That is incorrect since MDNodes can be modified by passes run between doInitialization and doFinalization. To fix the problem, we handle debug info MDNodes that can be reached from a function in runOnFunction (i.e we collect those nodes by calling processDeclare, processValue and processLocation, and then verify them in runOnFunction). We handle debug info MDNodes that can be reached from named metadata in doFinalization. This is in line with how Verifier handles module-level data (they are verified in doFinalization). rdar://15472296 llvm-svn: 194974
* Debug Info Verifier: enable public functions of Finder to update the type map.Manman Ren2013-11-172-8/+21
| | | | | | | | | | We used to depend on running processModule before the other public functions such as processDeclare, processValue and processLocation. We are now relaxing the constraint by adding a module argument to the three functions and letting the three functions to initialize the type map. This will be used in a follow-on patch that collects nodes reachable from a Function. llvm-svn: 194973
* Debug Info Verifier: remove un-used argument in verifyDebugInfo.Manman Ren2013-11-161-3/+3
| | | | | | No functionality change. llvm-svn: 194917
* [weak vtables] Remove a bunch of weak vtablesJuergen Ributzka2013-11-154-11/+5
| | | | | | | | | | | 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
* [PM] Fix an iterator problem spotted by the MSVC debug iterators andChandler Carruth2013-11-151-8/+10
| | | | | | AaronBallman. Thanks for the excellent review. llvm-svn: 194857
* [PM] Run clang-format on a few lines that I missed in my first pass,Chandler Carruth2013-11-151-2/+2
| | | | | | pulling them under 80-columns. No functionality changed. llvm-svn: 194856
* llvm-cov: Clean up memory leaks.Benjamin Kramer2013-11-151-1/+1
| | | | llvm-svn: 194799
* Add addrspacecast instruction.Matt Arsenault2013-11-158-133/+287
| | | | | | Patch by Michele Scandale! llvm-svn: 194760
* IR/GCOV.cpp: Use PRIu64 as format string with uint64_t.NAKAMURA Takumi2013-11-141-1/+1
| | | | llvm-svn: 194693
* Whitespace.NAKAMURA Takumi2013-11-141-3/+2
| | | | llvm-svn: 194692
* llvm-cov: Slightly improved error checking.Yuchen Wu2013-11-141-0/+4
| | | | | | | | - readInt() should check all 4 bytes can be read, not just 1. - In the event of false data in the gcno file, it was possible to index into a non-existent index of SmallVector, causing assertion error. llvm-svn: 194639
* llvm-cov: Removed StringMap holding GCOVLines.Yuchen Wu2013-11-141-39/+15
| | | | | | | | | | | | | | | | | According to the hazy gcov documentation, it appeared to be technically possible for lines within a block to belong to different source files. However, upon further investigation, gcov does not actually support multiple source files for a single block. This change removes a level of separation between blocks and lines by replacing the StringMap of GCOVLines with a SmallVector of ints representing line numbers. This also means that the GCOVLines class is no longer needed. This paves the way for supporting the "-a" option, which will output block information. llvm-svn: 194637
* llvm-cov: Replaced asserts with proper error handling.Yuchen Wu2013-11-141-44/+79
| | | | | | | | | | | | | | Unified the interface for read functions. They all return a boolean indicating if the read from file succeeded. Functions that previously returned the read value now store it into a variable that is passed in by reference instead. Callers will need to check the return value to detect if an error occurred. Also added a new test which ensures that no assertions occur when file contains invalid data. llvm-cov should return with error code 1 upon failure. llvm-svn: 194635
* Don't call doFinalization from verifyFunction.Rafael Espindola2013-11-131-1/+0
| | | | | | | | | | | | | | | | verifyFunction needs to call doInitialization to collect metadata and avoid crashing when verifying debug info in a function. But it should not call doFinalization since that is where the verifier will check declarations, variables and aliases, which is not desirable when one only wants to verify a function. A possible cleanup would be to split the class into a ModuleVerifier and FunctionVerifier. Issue reported by Ilia Filippov. Patch by Michael Kruse. llvm-svn: 194574
* Introduce an AnalysisManager which is like a pass manager but with a lotChandler Carruth2013-11-132-0/+156
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Print new JavaScript calling conventions symbolically.Andrew Trick2013-11-111-0/+2
| | | | llvm-svn: 194427
* Simplify code. No functionality change.Benjamin Kramer2013-11-111-5/+1
| | | | llvm-svn: 194383
* IR: Refactor GEP range checks, reuse them for other parts of foldingDavid Majnemer2013-11-101-28/+51
| | | | llvm-svn: 194341
* Move the old pass manager infrastructure into a legacy namespace andChandler Carruth2013-11-092-13/+21
| | | | | | | | | | | | | | | | | | | 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
* Remove ^M from the file.Bill Wendling2013-11-081-1419/+1415
| | | | llvm-svn: 194251
* IR: Properly canonicalize PointerType in ConstantExpr GEPsDavid Majnemer2013-11-071-5/+6
| | | | | | | No additional test was needed, Other/constant-fold-gep.ll detects this just fine. llvm-svn: 194221
* IR: Do not canonicalize constant GEPs into an out-of-bounds array accessDavid Majnemer2013-11-071-1/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Consider a GEP of: i8* getelementptr ({ [2 x i8], i32, i8, [3 x i8] }* @main.c, i32 0, i32 0, i64 0) If we proceeded to GEP the aforementioned object by 8, would form a GEP of: i8* getelementptr ({ [2 x i8], i32, i8, [3 x i8] }* @main.c, i32 0, i32 0, i64 8) Note that we would go through the first array member, causing an out-of-bounds accesses. This is problematic because we might get fooled if we are trying to evaluate loads using this GEP, for example, based off of an object with a constant initializer where the array is zero. This fixes PR17732. Reviewers: nicholas, chandlerc, void Reviewed By: void CC: llvm-commits, echristo, void, aemerson Differential Revision: http://llvm-reviews.chandlerc.com/D2093 llvm-svn: 194220
OpenPOWER on IntegriCloud