summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Scalar
Commit message (Collapse)AuthorAgeFilesLines
...
* Add some additional fields to TTI::UnrollingPreferencesHal Finkel2014-04-011-4/+13
| | | | | | | | | | | | | | | | | | | In preparation for an upcoming commit implementing unrolling preferences for x86, this adds additional fields to the UnrollingPreferences structure: - PartialThreshold and PartialOptSizeThreshold - Like Threshold and OptSizeThreshold, but used when not fully unrolling. These are necessary because we need different thresholds for full unrolling from those used when partially unrolling (the full unrolling thresholds are generally going to be larger). - MaxCount - A cap on the unrolling factor when partially unrolling. This can be used by a target to prevent the unrolled loop from exceeding some resource limit independent of the loop size (such as number of branches). There should be no functionality change for any in-tree targets. llvm-svn: 205347
* Move partial/runtime unrolling late in the pipelineHal Finkel2014-03-311-0/+4
| | | | | | | | | | | | | | | | The generic (concatenation) loop unroller is currently placed early in the standard optimization pipeline. This is a good place to perform full unrolling, but not the right place to perform partial/runtime unrolling. However, most targets don't enable partial/runtime unrolling, so this never mattered. However, even some x86 cores benefit from partial/runtime unrolling of very small loops, and follow-up commits will enable this. First, we need to move partial/runtime unrolling late in the optimization pipeline (importantly, this is after SLP and loop vectorization, as vectorization can drastically change the size of a loop), while keeping the full unrolling where it is now. This change does just that. llvm-svn: 205264
* Revert "GVN: merge overflow intrinsics with non-overflow instructions."Erik Verbruggen2014-03-281-124/+58
| | | | | | | | | This reverts commit r203553, and follow-up commits r203558 and r203574. I will follow this up on the mailinglist to do it in a way that won't cause subtle PRE bugs. llvm-svn: 205009
* Treat lifetime.start'd memory like we treat freshly alloca'd memory. Patch ↵Nick Lewycky2014-03-261-4/+16
| | | | | | by Björn Steinbrink! llvm-svn: 204876
* [Constant Hoisting] Make the constant candidate map local to the ↵Juergen Ributzka2014-03-251-11/+14
| | | | | | collectConstantCandidates method. llvm-svn: 204758
* remove a bunch of unused private methodsNuno Lopes2014-03-232-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | found with a smarter version of -Wunused-member-function that I'm playwing with. Appologies in advance if I removed someone's WIP code. include/llvm/CodeGen/MachineSSAUpdater.h | 1 include/llvm/IR/DebugInfo.h | 3 lib/CodeGen/MachineSSAUpdater.cpp | 10 -- lib/CodeGen/PostRASchedulerList.cpp | 1 lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp | 10 -- lib/IR/DebugInfo.cpp | 12 -- lib/MC/MCAsmStreamer.cpp | 2 lib/Support/YAMLParser.cpp | 39 --------- lib/TableGen/TGParser.cpp | 16 --- lib/TableGen/TGParser.h | 1 lib/Target/AArch64/AArch64TargetTransformInfo.cpp | 9 -- lib/Target/ARM/ARMCodeEmitter.cpp | 12 -- lib/Target/ARM/ARMFastISel.cpp | 84 -------------------- lib/Target/Mips/MipsCodeEmitter.cpp | 11 -- lib/Target/Mips/MipsConstantIslandPass.cpp | 12 -- lib/Target/NVPTX/NVPTXISelDAGToDAG.cpp | 21 ----- lib/Target/NVPTX/NVPTXISelDAGToDAG.h | 2 lib/Target/PowerPC/PPCFastISel.cpp | 1 lib/Transforms/Instrumentation/AddressSanitizer.cpp | 2 lib/Transforms/Instrumentation/BoundsChecking.cpp | 2 lib/Transforms/Instrumentation/MemorySanitizer.cpp | 1 lib/Transforms/Scalar/LoopIdiomRecognize.cpp | 8 - lib/Transforms/Scalar/SCCP.cpp | 1 utils/TableGen/CodeEmitterGen.cpp | 2 24 files changed, 2 insertions(+), 261 deletions(-) llvm-svn: 204560
* [Constant Hoisting] Erase dead cast instructions.Juergen Ributzka2014-03-221-1/+1
| | | | | | | The cleanup code that removes dead cast instructions only removed them from the basic block, but didn't delete them. This fix erases them now too. llvm-svn: 204538
* [Constant Hoisting] Fix multiple entries for the same basic block in PHI nodes.Juergen Ributzka2014-03-221-3/+36
| | | | | | | | | | | | | | | | | | | | A PHI node usually has only one value/basic block pair per incoming basic block. In the case of a switch statement it is possible that a following PHI node may have more than one such pair per incoming basic block. E.g.: %0 = phi i64 [ 123456, %case2 ], [ 654321, %Entry ], [ 654321, %Entry ] This is valid and the verfier doesn't complain, because both values are the same. Constant hoisting materializes the constant for each operand separately and the value is still the same, but the variable names have changed. As a result the verfier can't recognize anymore that they are the same value and complains. This fix adds special update code for PHI node in constant hoisting to prevent this corner case. This fixes <rdar://problem/16394449> llvm-svn: 204537
* Sink: Don't sink static allocas from the entry blockTom Stellard2014-03-211-0/+7
| | | | | | | CodeGen treats allocas outside the entry block as dynamically sized stack objects. llvm-svn: 204473
* [Constant Hoisting] Make the constant materialization cost operand dependentJuergen Ributzka2014-03-211-7/+7
| | | | | | | | | Extend the target hook to take also the operand index into account when calculating the cost of the constant materialization. Related to <rdar://problem/16381500> llvm-svn: 204435
* [Constant Hoisting] Lazily compute the idom and cache the result.Juergen Ributzka2014-03-211-4/+43
| | | | | | Related to <rdar://problem/16381500> llvm-svn: 204434
* [Constant Hoisting] Change the algorithm to only track constants for ↵Juergen Ributzka2014-03-211-239/+321
| | | | | | | | | | | | | | | | | | | | | | | | instructions. Originally the algorithm would search for expensive constants and track their users, which could be instructions and constant expressions. This change only tracks the constants for instructions, but constant expressions are indirectly covered too. If an operand is an constant expression, then we look through the expression to find anny expensive constants. The algorithm keep now track of the instruction and the operand index where the constant is used. This allows more precise hoisting of constant materialization code for PHI instructions, because we only hoist to the basic block of the incoming operand. Before we had to find the idom of all PHI operands and hoist the materialization code there. This also makes updating of instructions easier. Before we had to keep track of the original constant, find it in the instructions, and then replace it. Now we can just simply update the operand. Related to <rdar://problem/16381500> llvm-svn: 204433
* [Constant Hoisting] Fix capitalization of function names.Juergen Ributzka2014-03-211-33/+34
| | | | llvm-svn: 204432
* [Constant Hoisting] Replace the MapVector with a separate Map and Vector to ↵Juergen Ributzka2014-03-211-38/+51
| | | | | | | | | | | keep track of constant candidates. This simplifies working with the constant candidates and removes the tight coupling between the map and the vector. Related to <rdar://problem/16381500> llvm-svn: 204431
* Revert "[Constant Hoisting] Extend coverage of the constant hoisting pass."Juergen Ributzka2014-03-201-391/+259
| | | | | | I will break this up into smaller pieces for review and recommit. llvm-svn: 204393
* [Constant Hoisting] Extend coverage of the constant hoisting pass.Juergen Ributzka2014-03-201-259/+391
| | | | | | | | | This commit extends the coverage of the constant hoisting pass, adds additonal debug output and updates the function names according to the style guide. Related to <rdar://problem/16381500> llvm-svn: 204389
* Tolerate unmangled names in sample profiles.Diego Novillo2014-03-181-6/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The compiler does not always generate linkage names. If a function has been inlined and its body elided, its linkage name may not be generated. When the binary executes, the profiler will use its unmangled name when attributing samples. This results in unmangled names in the input profile. We are currently failing hard when this happens. However, in this case all that happens is that we fail to attribute samples to the inlined function. While this means fewer optimization opportunities, it should not cause a compilation failure. This patch accepts all valid function names, regardless of whether they were mangled or not. Reviewers: chandlerc CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D3087 llvm-svn: 204142
* Consistent use of the noduplicate attribute.Eli Bendersky2014-03-171-1/+1
| | | | | | | | | The "noduplicate" attribute of call instructions is sometimes queried directly and sometimes through the cannotDuplicate() predicate. This patch streamlines all queries to use the cannotDuplicate() predicate. It also adds this predicate to InvokeInst, to mirror what CallInst has. llvm-svn: 204049
* Remove named Twine.David Blaikie2014-03-161-4/+2
| | | | | | | While technically correct, we generally disallow any instance of named Twines due to their subtlety. llvm-svn: 204016
* Remove some dead assignements found by scan-buildArnaud A. de Grandmaison2014-03-151-1/+1
| | | | llvm-svn: 204013
* LSR: Compress a pair (and get rid of the DenseMapInfo for it).Benjamin Kramer2014-03-151-33/+6
| | | | | | | Also convert a horrible hash function to use our hashing infrastructure. No functionality change. llvm-svn: 204008
* SampleProfile.cpp: Fix take #2. The issue was abuse of StringRef here.NAKAMURA Takumi2014-03-151-2/+4
| | | | llvm-svn: 203996
* SampleProfile.cpp: Quick fix to r203976 about abuse of Twine. The life of ↵NAKAMURA Takumi2014-03-151-5/+3
| | | | | | | Twine was too short. FIXME: DiagnosticInfoSampleProfile should not hold Twine&. llvm-svn: 203990
* Re-format SampleProfile.cpp with clang-format. No functional changes.Diego Novillo2014-03-141-2/+2
| | | | llvm-svn: 203977
* Use DiagnosticInfo facility.Diego Novillo2014-03-141-14/+46
| | | | | | | | | | | | | | | | | | Summary: The sample profiler pass emits several error messages. Instead of just aborting the compiler with report_fatal_error, we can emit better messages using DiagnosticInfo. This adds a new sub-class of DiagnosticInfo to handle the sample profiler. Reviewers: chandlerc, qcolombet CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D3086 llvm-svn: 203976
* Fix typo in comment: "inwoke" -> "invoke"Mark Seaborn2014-03-131-1/+1
| | | | llvm-svn: 203739
* Fix crash in PRE.Erik Verbruggen2014-03-111-0/+2
| | | | | | | | | | After r203553 overflow intrinsics and their non-intrinsic (normal) instruction get hashed to the same value. This patch prevents PRE from moving an instruction into a predecessor block, and trying to add a phi node that gets two different types (the intrinsic result and the non-intrinsic result), resulting in a failing assert. llvm-svn: 203574
* GVN: fix hashing of extractvalue.Erik Verbruggen2014-03-111-0/+4
| | | | | | | My last commit did not add the indexes to the hashed value for extractvalue. Adding that back in. llvm-svn: 203558
* GVN: merge overflow intrinsics with non-overflow instructions.Erik Verbruggen2014-03-111-58/+118
| | | | | | | | | | | | | | | | | | | When an overflow intrinsic is followed by a non-overflow instruction, replace the latter with an extract. For example: %sadd = tail call { i32, i1 } @llvm.sadd.with.overflow.i32(i32 %a, i32 %b) %sadd3 = add i32 %a, %b Here the add statement will be replaced by an extract. When an overflow intrinsic follows a non-overflow instruction, a clone of the intrinsic is inserted before the normal instruction, which makes it the same as the previous case. Subsequent runs of GVN can then clean up the duplicate instructions and insert the extract. This fixes PR8817. llvm-svn: 203553
* Use discriminator information in sample profiles.Diego Novillo2014-03-101-40/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When the sample profiles include discriminator information, use the discriminator values to distinguish instruction weights in different basic blocks. This modifies the BodySamples mapping to map <line, discriminator> pairs to weights. Instructions on the same line but different blocks, will use different discriminator values. This, in turn, means that the blocks may have different weights. Other changes in this patch: - Add tests for positive values of line offset, discriminator and samples. - Change data types from uint32_t to unsigned and int and do additional validation. Reviewers: chandlerc CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2857 llvm-svn: 203508
* MemCpyOpt: When merging memsets also merge the trivial case of two memsets ↵Benjamin Kramer2014-03-101-0/+7
| | | | | | | | with the same destination. The testcase is from PR19092, but I think the bug described there is actually a clang issue. llvm-svn: 203489
* [C++11] Add range based accessors for the Use-Def chain of a Value.Chandler Carruth2014-03-0921-301/+238
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This requires a number of steps. 1) Move value_use_iterator into the Value class as an implementation detail 2) Change it to actually be a *Use* iterator rather than a *User* iterator. 3) Add an adaptor which is a User iterator that always looks through the Use to the User. 4) Wrap these in Value::use_iterator and Value::user_iterator typedefs. 5) Add the range adaptors as Value::uses() and Value::users(). 6) Update *all* of the callers to correctly distinguish between whether they wanted a use_iterator (and to explicitly dig out the User when needed), or a user_iterator which makes the Use itself totally opaque. Because #6 requires churning essentially everything that walked the Use-Def chains, I went ahead and added all of the range adaptors and switched them to range-based loops where appropriate. Also because the renaming requires at least churning every line of code, it didn't make any sense to split these up into multiple commits -- all of which would touch all of the same lies of code. The result is still not quite optimal. The Value::use_iterator is a nice regular iterator, but Value::user_iterator is an iterator over User*s rather than over the User objects themselves. As a consequence, it fits a bit awkwardly into the range-based world and it has the weird extra-dereferencing 'operator->' that so many of our iterators have. I think this could be fixed by providing something which transforms a range of T&s into a range of T*s, but that *can* be separated into another patch, and it isn't yet 100% clear whether this is the right move. However, this change gets us most of the benefit and cleans up a substantial amount of code around Use and User. =] llvm-svn: 203364
* [C++11] Convert sort predicates into lambdas.Benjamin Kramer2014-03-071-13/+8
| | | | | | No functionality change. llvm-svn: 203288
* Replace OwningPtr<T> with std::unique_ptr<T>.Ahmed Charles2014-03-061-4/+3
| | | | | | | | | | This compiles with no changes to clang/lld/lldb with MSVC and includes overloads to various functions which are used by those projects and llvm which have OwningPtr's as parameters. This should allow out of tree projects some time to move. There are also no changes to libs/Target, which should help out of tree targets have time to move, if necessary. llvm-svn: 203083
* [Layering] Move InstVisitor.h into the IR library as it is prettyChandler Carruth2014-03-063-3/+3
| | | | | | obviously coupled to the IR. llvm-svn: 203064
* [Layering] Move DebugInfo.h into the IR library where its implementationChandler Carruth2014-03-063-3/+3
| | | | | | already lives. llvm-svn: 203046
* [Layering] Move DIBuilder.h into the IR library where its implementationChandler Carruth2014-03-062-2/+2
| | | | | | already lives. llvm-svn: 203038
* [C++11] Make this interface accept const Use pointers and use overrideChandler Carruth2014-03-051-2/+2
| | | | | | | | to ensure we don't mess up any of the overrides. Necessary for cleaning up the Value use iterators and enabling range-based traversing of use lists. llvm-svn: 202958
* [C++11] Add 'override' keyword to virtual methods that override their base ↵Craig Topper2014-03-0535-100/+101
| | | | | | class. llvm-svn: 202953
* [Modules] Move the PredIteratorCache into the IR library -- it isChandler Carruth2014-03-041-1/+1
| | | | | | hardcoded to use IR BasicBlocks. llvm-svn: 202835
* [Modules] Move CFG.h to the IR library as it defines graph traits overChandler Carruth2014-03-0411-11/+11
| | | | | | IR types. llvm-svn: 202827
* [Modules] Move ValueHandle into the IR library where Value itself lives.Chandler Carruth2014-03-044-4/+4
| | | | | | | | | | | Move the test for this class into the IR unittests as well. This uncovers that ValueMap too is in the IR library. Ironically, the unittest for ValueMap is useless in the Support library (honestly, so was the ValueHandle test) and so it already lives in the IR unittests. Mmmm, tasty layering. llvm-svn: 202821
* [Modules] Move the LLVM IR pattern match header into the IR library, itChandler Carruth2014-03-042-2/+2
| | | | | | obviously is coupled to the IR. llvm-svn: 202818
* [Modules] Move CallSite into the IR library where it belogs. It isChandler Carruth2014-03-043-3/+3
| | | | | | | abstracting between a CallInst and an InvokeInst, both of which are IR concepts. llvm-svn: 202816
* [Modules] Move GetElementPtrTypeIterator into the IR library. As itsChandler Carruth2014-03-042-2/+2
| | | | | | | | | name might indicate, it is an iterator over the types in an instruction in the IR.... You see where this is going. Another step of modularizing the support library. llvm-svn: 202815
* [Modules] Move InstIterator out of the Support library, where it had noChandler Carruth2014-03-044-4/+4
| | | | | | | | | | | | | business. This header includes Function and BasicBlock and directly uses the interfaces of both classes. It has to do with the IR, it even has that in the name. =] Put it in the library it belongs to. This is one step toward making LLVM's Support library survive a C++ modules bootstrap. llvm-svn: 202814
* [C++11] Use std::tie to simplify compare operators.Benjamin Kramer2014-03-031-15/+5
| | | | | | No functionality change. llvm-svn: 202751
* [C++11] Remove a leftover std::function instance.Benjamin Kramer2014-03-031-3/+2
| | | | | | It's not needed anymore. llvm-svn: 202748
* [C++11] Remove the completely unnecessary requirement on SetVector'sChandler Carruth2014-03-032-4/+3
| | | | | | | | | | | | remove_if that its predicate is adaptable. We don't actually need this, we can write a generic adapter for any predicate. This lets us remove some very wrong std::function usages. We should never be using std::function for predicates to algorithms. This incurs an *indirect* call overhead for every evaluation of the predicate, and makes it very hard to inline through. llvm-svn: 202742
* [C++11] Add a basic block range view for RegionInfoTobias Grosser2014-03-031-6/+1
| | | | | | This also switches the users in LLVM to ensure this functionality is tested. llvm-svn: 202705
OpenPOWER on IntegriCloud