summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Utils
Commit message (Collapse)AuthorAgeFilesLines
* The DIBuilder class is just a wrapper around debug info creationBill Wendling2012-06-292-2/+2
| | | | | | | (a.k.a. MDNodes). The module doesn't belong in Analysis. Move it to the VMCore instead. llvm-svn: 159414
* Move lib/Analysis/DebugInfo.cpp to lib/VMCore/DebugInfo.cpp andBill Wendling2012-06-284-5/+5
| | | | | | | | | include/llvm/Analysis/DebugInfo.h to include/llvm/DebugInfo.h. The reasoning is because the DebugInfo module is simply an interface to the debug info MDNodes and has nothing to do with analysis. llvm-svn: 159312
* The name (and comment describing) of llvm::GetFirstDebuigLocInBasicBlock no ↵Eli Bendersky2012-06-252-11/+5
| | | | | | longer represents what the function does. Therefore, the function is removed and its functionality is folded into the only place in the code-base where it was being used. llvm-svn: 159133
* llvm/lib: [CMake] Add explicit dependency to intrinsics_gen.NAKAMURA Takumi2012-06-241-0/+2
| | | | llvm-svn: 159112
* Remove dyn_cast + dereference pattern by replacing it with a cast and changingNick Lewycky2012-06-241-3/+3
| | | | | | | the safety check to look for the same type we're going to actually cast to. Fixes PR13180! llvm-svn: 159110
* Extend the IL for selecting TLS models (PR9788)Hans Wennborg2012-06-231-1/+1
| | | | | | | | | | | | | | | This allows the user/front-end to specify a model that is better than what LLVM would choose by default. For example, a variable might be declared as @x = thread_local(initialexec) global i32 42 if it will not be used in a shared library that is dlopen'ed. If the specified model isn't supported by the target, or if LLVM can make a better choice, a different model may be used. llvm-svn: 159077
* Optimized usage of new SwitchInst case values (IntegersSubset type) in ↵Stepan Dyatkovskiy2012-06-231-4/+3
| | | | | | | | Local.cpp, Execution.cpp and BitcodeWriter.cpp. I got about 1% of compile-time improvement on my machines (Ubuntu 11.10 i386 and Ubuntu 12.04 x64). llvm-svn: 159076
* Fixed r158979.Stepan Dyatkovskiy2012-06-221-1/+2
| | | | | | | | | | Original message: Performance optimizations: - SwitchInst: case values stored separately from Operands List. It allows to make faster access to individual case value numbers or ranges. - Optimized IntItem, added APInt value caching. - Optimized IntegersSubsetGeneric: added optimizations for cases when subset is single number or when subset consists from single numbers only. llvm-svn: 158997
* refactor the MemoryBuiltin analysis:Nuno Lopes2012-06-211-1/+1
| | | | | | | | | | | | - provide more extensive set of functions to detect library allocation functions (e.g., malloc, calloc, strdup, etc) - provide an API to compute the size and offset of an object pointed by Move a few clients (GVN, AA, instcombine, ...) to the new API. This implementation is a lot more aggressive than each of the custom implementations being replaced. Patch reviewed by Nick Lewycky and Chandler Carruth, thanks. llvm-svn: 158919
* Fix two rather subtle internal vs. external linker issues.Chandler Carruth2012-06-201-25/+20
| | | | | | | | | | | | | | | | | | | | | | I'll admit I'm not entirely satisfied with this change, but it seemed the cleanest option. Other suggestions quite welcome The issue is that the traits specializations have static methods which return the typedef'ed PHI_iterator type. In both the IR and MI layers this is typedef'ed to a custom iterator class defined in an anonymous namespace giving the types and the functions returning them internal linkage. However, because the traits specialization is defined in the 'llvm' namespace (where it has to be, specialized template lives there), and is in turn used in the templated implementation of the SSAUpdater. This led to the linkage conflict that Clang now warns about. The simplest solution to me was just to define the PHI_iterator as a nested class inside the trait specialization. That way it still doesn't get scoped widely, it can't be accidentally reused somewhere, etc. This is a little gross just because nested class definitions are a little gross, but the alternatives seem more ad-hoc. llvm-svn: 158799
* SimplifyCFG: fold unconditional branch to its predecessor if profitable.Manman Ren2012-06-131-24/+180
| | | | | | | | | | This patch extends FoldBranchToCommonDest to fold unconditional branches. For unconditional branches, we fold them if it is easy to update the phi nodes in the common successors. rdar://10554090 llvm-svn: 158392
* Convert comments to proper Doxygen comments.Dmitri Gribenko2012-06-091-4/+4
| | | | llvm-svn: 158248
* Remove unused private fields found by clang's new -Wunused-private-field.Benjamin Kramer2012-06-061-2/+0
| | | | | | | | There are some that I didn't remove this round because they looked like obvious stubs. There are dead variables in gtest too, they should be fixed upstream. llvm-svn: 158090
* LoopUnroll: always check for NULL LoopPassManagerAndrew Trick2012-06-051-3/+5
| | | | llvm-svn: 158007
* Fix typos found by http://github.com/lyda/misspell-checkBenjamin Kramer2012-06-022-2/+2
| | | | llvm-svn: 157885
* PR1255: case ranges.Stepan Dyatkovskiy2012-06-022-4/+4
| | | | | | IntRange converted from struct to class. So main change everywhere is replacement of ".Low/High" with ".getLow/getHigh()" llvm-svn: 157884
* ConstantRangesSet renamed to IntegersSubset. CRSBuilder renamed to ↵Stepan Dyatkovskiy2012-05-292-8/+8
| | | | | | IntegersSubsetMapping. llvm-svn: 157612
* PR1255: Case RangesStepan Dyatkovskiy2012-05-282-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | Implemented IntItem - the wrapper around APInt. Why not to use APInt item directly right now? 1. It will very difficult to implement case ranges as series of small patches. We got several large and heavy patches. Each patch will about 90-120 kb. If you replace ConstantInt with APInt in SwitchInst you will need to changes at the same time all Readers,Writers and absolutely all passes that uses SwitchInst. 2. We can implement APInt pool inside and save memory space. E.g. we use several switches that works with 256 bit items (switch on signatures, or strings). We can avoid value duplicates in this case. 3. IntItem can be easyly easily replaced with APInt. 4. Currenly we can interpret IntItem both as ConstantInt and as APInt. It allows to provide SwitchInst methods that works with ConstantInt for non-updated passes. Why I need it right now? Currently I need to update SimplifyCFG pass (EqualityComparisons). I need to work with APInts directly a lot, so peaces of code ConstantInt *V = ...; if (V->getValue().ugt(AnotherV->getValue()) { ... } will look awful. Much more better this way: IntItem V = ConstantIntVal->getValue(); if (AnotherV < V) { } Of course any reviews are welcome. P.S.: I'm also going to rename ConstantRangesSet to IntegersSubset, and CRSBuilder to IntegersSubsetMapping (allows to map individual subsets of integers to the BasicBlocks). Since in future these classes will founded on APInt, it will possible to use them in more generic ways. llvm-svn: 157576
* switch AttrListPtr::get to take an ArrayRef, simplifying a lot of clients.Chris Lattner2012-05-281-12/+12
| | | | llvm-svn: 157556
* SimplifyCFG: Turn the ad-hoc std::pair that represents switch cases into an ↵Benjamin Kramer2012-05-261-39/+54
| | | | | | explicit struct. llvm-svn: 157516
* Add support for branch weight metadata to MDBuilder and use it in various ↵Benjamin Kramer2012-05-262-32/+23
| | | | | | places. llvm-svn: 157515
* PR1255 related changes (case ranges):Stepan Dyatkovskiy2012-05-241-40/+18
| | | | | | | LowerSwitch::Clusterify : main functinality was replaced with CRSBuilder::optimize, so big part of Clusterify's code was reduced. test/Transform/LowerSwitch/feature.ll - this test was refactored: grep + count was replaced with FileCheck usage. llvm-svn: 157384
* PR1255(case ranges) related changes in Local Transformations.Stepan Dyatkovskiy2012-05-231-10/+14
| | | | llvm-svn: 157315
* teach DSE and isInstructionTriviallyDead() about callocNuno Lopes2012-05-101-1/+1
| | | | llvm-svn: 156553
* Allow NULL LoopPassManager argument in UnrollLoop. PR12734.Andrew Trick2012-05-082-20/+26
| | | | llvm-svn: 156358
* Teach the code extractor how to extract a sequence of blocks fromChandler Carruth2012-05-041-7/+32
| | | | | | | RegionInfo's RegionNode. This mirrors the logic for automating the extraction from a Loop. llvm-svn: 156208
* Factor the computation of input and output sets into a public interfaceChandler Carruth2012-05-041-35/+34
| | | | | | | | | | | | | | | | of the CodeExtractor utility. This allows speculatively computing input and output sets to measure the likely size impact of the code extraction. These sets cannot be reused sadly -- we mutate the function prior to forming the final sets used by the actual extraction. The interface has been revamped slightly to make it easier to use correctly by making the interface const and sinking the computation of the number of exit blocks into the full extraction function and away from the rest of this logic which just computed two output parameters. llvm-svn: 156168
* Rather than trying to gracefully handle input sequences with repeatedChandler Carruth2012-05-041-1/+1
| | | | | | | blocks, assert that this doesn't happen. We don't want to bother trying to support this call pattern as it isn't necessary. llvm-svn: 156167
* Fix a goof with my previous commit by completely returning when weChandler Carruth2012-05-041-1/+1
| | | | | | detect an in-eligible block rather than just breaking out of the loop. llvm-svn: 156166
* Hoist a safety assert from the extraction method into the constructionChandler Carruth2012-05-041-9/+13
| | | | | | of the extractor itself. llvm-svn: 156164
* Move the CodeExtractor utility to a dedicated header file / source file,Chandler Carruth2012-05-041-161/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | | and expose it as a utility class rather than as free function wrappers. The simple free-function interface works well for the bugpoint-specific pass's uses of code extraction, but in an upcoming patch for more advanced code extraction, they simply don't expose a rich enough interface. I need to expose various stages of the process of doing the code extraction and query information to decide whether or not to actually complete the extraction or give up. Rather than build up a new predicate model and pass that into these functions, just take the class that was actually implementing the functions and lift it up into a proper interface that can be used to perform code extraction. The interface is cleaned up and re-documented to work better in a header. It also is now setup to accept the blocks to be extracted in the constructor rather than in a method. In passing this essentially reverts my previous commit here exposing a block-level query for eligibility of extraction. That is no longer necessary with the more rich interface as clients can query the extraction object for eligibility directly. This will reduce the number of walks of the input basic block sequence by quite a bit which is useful if this enters the normal optimization pipeline. llvm-svn: 156163
* Factor the logic for testing whether a basic block is viable for codeChandler Carruth2012-05-031-14/+21
| | | | | | | | | | | extraction into a public interface. Also clean it up and apply it more consistently such that we check for landing pads *anywhere* in the extracted code, not just in single-block extraction. This will be used to guide decisions in passes that are planning to eventually perform a round of code extraction. llvm-svn: 156114
* Second attempt at PR12573:Bill Wendling2012-04-301-11/+26
| | | | | | | | | | | Allow the "SplitCriticalEdge" function to split the edge to a landing pad. If the pass is *sure* that it thinks it knows what it's doing, then it may go ahead and specify that the landing pad can have its critical edge split. The loop unswitch pass is one of these passes. It will split the critical edges of all edges coming from a loop to a landing pad not within the loop. Doing so will retain important loop analysis information, such as loop simplify. llvm-svn: 155817
* Use an ArrayRef instead of explicit vector type.Bill Wendling2012-04-301-8/+5
| | | | llvm-svn: 155816
* Fix 12513: Loop unrolling breaks with indirect branches.Andrew Trick2012-04-101-0/+6
| | | | | | | | Take this opportunity to generalize the indirectbr bailout logic for loop transformations. CFG transformations will never get indirectbr right, and there's no point trying. llvm-svn: 154386
* Sink the collection of return instructions until after *all*Chandler Carruth2012-04-061-7/+9
| | | | | | | | | | | simplification has been performed. This is a bit less efficient (requires another ilist walk of the basic blocks) but shouldn't matter in practice. More importantly, it's just too much work to keep track of all the various ways the return instructions can be mutated while simplifying them. This fixes yet another crasher, reported by Daniel Dunbar. llvm-svn: 154179
* Sink the return instruction collection until after we're done deletingChandler Carruth2012-04-061-7/+9
| | | | | | | | | | | | | | dead code, including dead return instructions in some cases. Otherwise, we end up having a bogus poniter to a return instruction that blows up much further down the road. It turns out that this pattern is both simpler to code, easier to update in the face of enhancements to the inliner cleanup, and likely cheaper given that it won't add dead instructions to the list. Thanks to John Regehr's numerous test cases for teasing this out. llvm-svn: 154157
* Always compute all the bits in ComputeMaskedBits.Rafael Espindola2012-04-042-3/+2
| | | | | | | | This allows us to keep passing reduced masks to SimplifyDemandedBits, but know about all the bits if SimplifyDemandedBits fails. This allows instcombine to simplify cases like the one in the included testcase. llvm-svn: 154011
* Switch to WeakVHs in the value mapper, and aggressively prune dead basicChandler Carruth2012-03-281-3/+23
| | | | | | | | | blocks in the function cloner. This removes the last case of trivially dead code that I've been seeing in the wild getting inlined, analyzed, re-inlined, optimized, only to be deleted. Nukes a FIXME from the cleanup tests. llvm-svn: 153572
* Tidy.Eric Christopher2012-03-261-1/+1
| | | | llvm-svn: 153456
* Tidy.Eric Christopher2012-03-261-6/+9
| | | | llvm-svn: 153455
* Teach the function cloner (and thus the inliner) to simplify PHINodesChandler Carruth2012-03-251-12/+18
| | | | | | | | | | | | | | | | | | | | aggressively. There are lots of dire warnings about this being expensive that seem to predate switching to the TrackingVH-based value remapper that is automatically updated on RAUW. This makes it easy to not just prune single-entry PHIs, but to fully simplify PHIs, and to recursively simplify the newly inlined code to propagate PHINode simplifications. This introduces a bit of a thorny problem though. We may end up simplifying a branch condition to a constant when we fold PHINodes, and we would like to nuke any dead blocks resulting from this so that time isn't wasted continually analyzing them, but this isn't easy. Deleting basic blocks *after* they are fully cloned and mapped into the new function currently requires manually updating the value map. The last piece of the simplification-during-inlining puzzle will require either switching to WeakVH mappings or some other piece of refactoring. I've left a FIXME in the testcase about this. llvm-svn: 153410
* Move the instruction simplification of callsite arguments in the inlinerChandler Carruth2012-03-251-53/+33
| | | | | | | | | | | | | | | | | | | | | | | to instead rely on much more generic and powerful instruction simplification in the function cloner (and thus inliner). This teaches the pruning function cloner to use instsimplify rather than just the constant folder to fold values during cloning. This can simplify a large number of things that constant folding alone cannot begin to touch. For example, it will realize that 'or' and 'and' instructions with certain constant operands actually become constants regardless of what their other operand is. It also can thread back through the caller to perform simplifications that are only possible by looking up a few levels. In particular, GEPs and pointer testing tend to fold much more heavily with this change. This should (in some cases) have a positive impact on compile times with optimizations on because the inliner itself will simply avoid cloning a great deal of code. It already attempted to prune proven-dead code, but now it will be use the stronger simplifications to prove more code dead. llvm-svn: 153403
* Add an asserting ValueHandle to the block simplification code which willChandler Carruth2012-03-251-0/+9
| | | | | | | | | | | | | | | | fire if anything ever invalidates the assumption of a terminator instruction being unchanged throughout the routine. I've convinced myself that the current definition of simplification precludes such a transformation, so I think getting some asserts coverage that we don't violate this agreement is sufficient to make this code safe for the foreseeable future. Comments to the contrary or other suggestions are of course welcome. =] The bots are now happy with this code though, so it appears the bug here has indeed been fixed. llvm-svn: 153401
* Don't form a WeakVH around the sentinel node in the instructions BBChandler Carruth2012-03-241-4/+2
| | | | | | | | | | | | | | | | | | | list. This is a bad idea. ;] I'm hopeful this is the bug that's showing up with the MSVC bots, but we'll see. It is definitely unnecessary. InstSimplify won't do anything to a terminator instruction, we don't need to even include it in the iteration range. We can also skip the now dead terminator check, although I've made it an assert to help document that this is an important invariant. I'm still a bit queasy about this because there is an implicit assumption that the terminator instruction cannot be RAUW'ed by the simplification code. While that appears to be true at the moment, I see no guarantee that would ensure it remains true in the future. I'm looking at the cleanest way to solve that... llvm-svn: 153399
* Refactor the interface to recursively simplifying instructions to be tadChandler Carruth2012-03-241-14/+6
| | | | | | | | | | | | | | | | | | | | | | | | | bit simpler by handling a common case explicitly. Also, refactor the implementation to use a worklist based walk of the recursive users, rather than trying to use value handles to detect and recover from RAUWs during the recursive descent. This fixes a very subtle bug in the previous implementation where degenerate control flow structures could cause mutually recursive instructions (PHI nodes) to collapse in just such a way that From became equal to To after some amount of recursion. At that point, we hit the inf-loop that the assert at the top attempted to guard against. This problem is defined away when not using value handles in this manner. There are lots of comments claiming that the WeakVH will protect against just this sort of error, but they're not accurate about the actual implementation of WeakVHs, which do still track RAUWs. I don't have any test case for the bug this fixes because it requires running the recursive simplification on unreachable phi nodes. I've no way to either run this or easily write an input that triggers it. It was found when using instruction simplification inside the inliner when running over the nightly test-suite. llvm-svn: 153393
* Remove unused simplifyIVUsersAndrew Trick2012-03-221-41/+0
| | | | llvm-svn: 153262
* Zap some dead code pointed out by Chandler.Eric Christopher2012-03-201-4/+0
| | | | llvm-svn: 153150
* LoopSimplify bug fix. Handle indirect loop back edges.Andrew Trick2012-03-201-5/+8
| | | | | | | | Do not call SplitBlockPredecessors on a loop preheader when one of the predecessors is an indirectbr. Otherwise, you will hit this assert: !isa<IndirectBrInst>(Preds[i]->getTerminator()) && "Cannot split an edge from an IndirectBrInst" llvm-svn: 153134
* whitespaceAndrew Trick2012-03-201-2/+2
| | | | llvm-svn: 153133
OpenPOWER on IntegriCloud