summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Scalar
Commit message (Collapse)AuthorAgeFilesLines
* [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
* [C++11] Add two range adaptor views to User: operands andChandler Carruth2014-03-031-6/+5
| | | | | | | | | | | | | | | | | | operand_values. The first provides a range view over operand Use objects, and the second provides a range view over the Value*s being used by those operands. The naming is "STL-style" rather than "LLVM-style" because we have historically named iterator methods STL-style, and range methods seem to have far more in common with their iterator counterparts than with "normal" APIs. Feel free to bikeshed on this one if you want, I'm happy to change these around if people feel strongly. I've switched code in SROA and LCG to exercise these mostly to ensure they work correctly -- we don't really have an easy way to unittest this and they're trivial. llvm-svn: 202687
* [C++11] Replace llvm::tie with std::tie.Benjamin Kramer2014-03-022-3/+3
| | | | | | The old implementation is no longer needed in C++11. llvm-svn: 202644
* [C++11] Replace llvm::next and llvm::prior with std::next and std::prev.Benjamin Kramer2014-03-027-24/+25
| | | | | | Remove the old functions. llvm-svn: 202636
* Switch all uses of LLVM_OVERRIDE to just use 'override' directly.Craig Topper2014-03-021-3/+3
| | | | llvm-svn: 202621
* [C++11] Switch all uses of the llvm_move macro to use std::moveChandler Carruth2014-03-021-1/+1
| | | | | | directly, and remove the macro. llvm-svn: 202612
* Now that we have C++11, turn simple functors into lambdas and remove a ton ↵Benjamin Kramer2014-03-014-89/+28
| | | | | | | | of boilerplate. No intended functionality change. llvm-svn: 202588
* Fix PR18165: LSR must avoid scaling factors that exceed the limit on ↵Andrew Trick2014-02-261-0/+12
| | | | | | | | truncated use. Patch by Michael Zolotukhin! llvm-svn: 202273
* [SROA] Use the correct index integer size in GEPs through non-defaultChandler Carruth2014-02-261-5/+10
| | | | | | | | | | | address spaces. This isn't really a correctness issue (the values are truncated) but its much cleaner. Patch by Matt Arsenault! llvm-svn: 202252
* [SROA] Teach SROA how to handle pointers from address spaces other thanChandler Carruth2014-02-261-9/+14
| | | | | | | | | | | | | | | the default. Based on the patch by Matt Arsenault, D1764! I switched one place to use the more direct pointer type to compute the desired address space, and I reworked the memcpy rewriting section to reflect significant refactorings that this patch helped inspire. Thanks to several of the folks who helped review and improve the patch as well. llvm-svn: 202247
* [SROA] Split the alignment computation complete for the memcpy rewritingChandler Carruth2014-02-261-16/+16
| | | | | | | | | | | | | to work independently for the slice side and the other side. This allows us to only compute the minimum of the two when we actually rewrite to a memcpy that needs to take the minimum, and preserve higher alignment for one side or the other when rewriting to loads and stores. This fix was inspired by seeing the result of some refactoring that makes addrspace handling better. llvm-svn: 202242
* [SROA] The original refactoring inspired by the addrspace patch inChandler Carruth2014-02-261-21/+21
| | | | | | | | | | | | | | | | | | | | | | D1764, which in turn set off the other refactorings to make 'getSliceAlign()' a sensible thing. There are two possible inputs to the required alignment of a memory transfer intrinsic: the alignment constraints of the source and the destination. If we are *only* introducing a (potentially new) offset onto one side of the transfer, we don't need to consider the alignment constraints of the other side. Use this to simplify the logic feeding into alignment computation for unsplit transfers. Also, hoist the clamp of the magical zero alignment for these intrinsics to the more customary one alignment early. This lets several other conditions melt away. No functionality changed. There is a further improvement this exposes which *will* change functionality, but that's arriving in a separate patch. llvm-svn: 202232
* [SROA] Yet another slight refactoring that simplifies an API in theChandler Carruth2014-02-261-20/+19
| | | | | | | | | | | | | | | | rewriting logic: don't pass custom offsets for the adjusted pointer to the new alloca. We always passed NewBeginOffset here. Sometimes we spelled it BeginOffset, but only when they were in fact equal. Whats worse, the API is set up so that you can't reasonably call it with anything else -- it assumes that you're passing it an offset relative to the *original* alloca that happens to fall within the new one. That's the whole point of NewBeginOffset, it's the clamped beginning offset. No functionality changed. llvm-svn: 202231
* [SROA] Simplify the computing of alignment: we only ever need theChandler Carruth2014-02-261-30/+16
| | | | | | | | | | | | | | | alignment of the slice being rewritten, not any arbitrary offset. Every caller is really just trying to compute the alignment for the whole slice, never for some arbitrary alignment. They are also just passing a type when they have one to see if we can skip an explicit alignment in the IR by using the type's alignment. This makes for a much simpler interface. Another refactoring inspired by the addrspace patch for SROA, although only loosely related. llvm-svn: 202230
* [SROA] Use NewOffsetBegin in the unsplit case for memset merely forChandler Carruth2014-02-261-3/+4
| | | | | | | | | | | | | | | | | consistency with memcpy rewriting, and fix a latent bug in the alignment management for memset. The alignment issue is that getAdjustedAllocaPtr is computing the *relative* offset into the new alloca, but the alignment isn't being set to the relative offset, it was using the the absolute offset which is into the old alloca. I don't think its possible to write a test case that actually reaches this code where the resulting alignment would be observably different, but the intent was clearly to use the relative offset within the new alloca. llvm-svn: 202229
* [SROA] Use the members for New{Begin,End}Offset in the rewrite helpersChandler Carruth2014-02-261-14/+8
| | | | | | | | | | | | | | | rather than passing them as arguments. While I generally prefer actual arguments, in this case the readability loss is substantial. By using members we avoid repeatedly calculating the offsets, and once we're using members it is useful to ensure that those names *always* refer to the original-alloca-relative new offset for a rewritten slice. No functionality changed. Follow-up refactoring, all toward getting the address space patch merged. llvm-svn: 202228
* [SROA] Compute the New{Begin,End}Offset values once for each allocaChandler Carruth2014-02-261-40/+24
| | | | | | | | | | | | | | slice being rewritten. We had the same code scattered across most of the visits. Instead, compute the new offsets and the slice size once when we start to visit a particular slice, and use the member variables from then on. This reduces quite a bit of code duplication. No functionality changed. Refactoring inspired to make it easier to apply the address space patch to SROA. llvm-svn: 202227
* [SROA] Fix PR18615 with some long overdue simplifications to the boundsChandler Carruth2014-02-261-9/+6
| | | | | | | | | | | | | | | | | | | | | | | | | checking in SROA. The primary change is to just rely on uge for checking that the offset is within the allocation size. This removes the explicit checks against isNegative which were terribly error prone (including the reversed logic that led to PR18615) and prevented us from supporting stack allocations larger than half the address space.... Ok, so maybe the latter isn't *common* but it's a silly restriction to have. Also, we used to try to support a PHI node which loaded from before the start of the allocation if any of the loaded bytes were within the allocation. This doesn't make any sense, we have never really supported loading or storing *before* the allocation starts. The simplified logic just doesn't care. We continue to allow loading past the end of the allocation in part to support cases where there is a PHI and some loads are larger than others and the larger ones reach past the end of the allocation. We could solve this a different and more conservative way, but I'm still somewhat paranoid about this. llvm-svn: 202224
* [reassociate] Switch two std::sort calls into std::stable_sort calls asChandler Carruth2014-02-251-2/+2
| | | | | | | | | | | | | | | their inputs come from std::stable_sort and they are not total orders. I'm not a huge fan of this, but the really bad std::stable_sort is right at the beginning of Reassociate. After we commit to stable-sort based consistent respect of source order, the downstream sorts shouldn't undo that unless they have a total order or they are used in an order-insensitive way. Neither appears to be true for these cases. I don't have particularly good test cases, but this jumped out by inspection when looking for output instability in this pass due to changes in the ordering of std::sort. llvm-svn: 202196
* [SROA] Add an off-by-default *strict* inbounds check to SROA. I had SROAChandler Carruth2014-02-251-0/+42
| | | | | | | | | | implemented this way a long time ago and due to the overwhelming bugs that surfaced, moved to a much more relaxed variant. Richard Smith would like to understand the magnitude of this problem and it seems fairly harmless to keep some flag-controlled logic to get the extremely strict behavior here. I'll remove it if it doesn't prove useful. llvm-svn: 202193
* Make DataLayout a plain object, not a pass.Rafael Espindola2014-02-2515-17/+36
| | | | | | | Instead, have a DataLayoutPass that holds one. This will allow parts of LLVM don't don't handle passes to also use DataLayout. llvm-svn: 202168
* Factor out calls to AA.getDataLayout().Rafael Espindola2014-02-251-8/+6
| | | | llvm-svn: 202157
* [SROA] Use the original load name with the SROA-prefixed IRB rather thanChandler Carruth2014-02-251-2/+2
| | | | | | | | just "load". This helps avoid pointless de-duping with order-sensitive numbers as we already have unique names from the original load. It also makes the resulting IR quite a bit easier to read. llvm-svn: 202140
* [SROA] Thread the ability to add a pointer-specific name prefix throughChandler Carruth2014-02-251-21/+53
| | | | | | | | | | | | | | | | | | | | | | | | the pointer adjustment code. This is the primary code path that creates totally new instructions in SROA and being able to lump them based on the pointer value's name for which they were created causes *significantly* fewer name collisions and general noise in the debug output. This is particularly significant because it is making it much harder to track down instability in the output of SROA, as name de-duplication is a totally harmless form of instability that gets in the way of seeing real problems. The new fancy naming scheme tries to dig out the root "pre-SROA" name for pointer values and associate that all the way through the pointer formation instructions. Digging out the root is important to prevent the multiple iterative rounds of SROA from just layering too much cruft on top of cruft here. We already track the layers of SROAs iteration in the alloca name prefix. We don't need to duplicate it here. Should have no functionality change, and shouldn't have any really measurable impact on NDEBUG builds, as most of the complex logic is debug-only. llvm-svn: 202139
* [SROA] Rather than copying the logic for building a name prefix into theChandler Carruth2014-02-251-3/+3
| | | | | | | PHI-pointer builder, just copy the builder and clobber the obvious fields. llvm-svn: 202136
* [SROA] Simplify some of the logic to dig out the old pointer value byChandler Carruth2014-02-251-14/+10
| | | | | | | | | using OldPtr more heavily. Lots of this code was written before the rewriter had an OldPtr member setup ahead of time. There are already asserts in place that should ensure this doesn't change any functionality. llvm-svn: 202135
* [SROA] Adjust to new clang-format style.Chandler Carruth2014-02-251-2/+2
| | | | llvm-svn: 202134
* [SROA] Fix a *glaring* bug in r202091: you have to actually *write*Chandler Carruth2014-02-251-0/+2
| | | | | | | | | | | | | | the break statement, not just think it to yourself.... No idea how this worked at all, much less survived most bots, my bootstrap, and some bot bootstraps! The Polly one didn't survive, and this was filed as PR18959. I don't have a reduced test case and honestly I'm not seeing the need. What we probably need here are better asserts / debug-build behavior in SmallPtrSet so that this madness doesn't make it so far. llvm-svn: 202129
* Silence GCC warningAlexey Samsonov2014-02-251-1/+1
| | | | llvm-svn: 202119
* Fix typosAlp Toker2014-02-251-1/+1
| | | | llvm-svn: 202107
* [SROA] Add a debugging tool which shuffles the slices sequence prior toChandler Carruth2014-02-251-0/+19
| | | | | | | | | | | | | sorting it. This helps uncover latent reliance on the original ordering which aren't guaranteed to be preserved by std::sort (but often are), and which are based on the use-def chain orderings which also aren't (technically) guaranteed. Only available in C++11 debug builds, and behind a flag to prevent noise at the moment, but this is generally useful so figured I'd put it in the tree rather than keeping it out-of-tree. llvm-svn: 202106
* [SROA] Use a more direct way of determining whether we are processingChandler Carruth2014-02-251-2/+3
| | | | | | | | | | | | | | | | | | the destination operand or source operand of a memmove. It so happens that it was impossible for SROA to try to rewrite self-memmove where the operands are *identical*, because either such a think is volatile (and we don't rewrite) or it is non-volatile, and we don't even register it as a use of the alloca. However, making the 'IsDest' test *rely* on this subtle fact is... Very confusing for the reader. We should use the direct and readily available test of the Use* which gives us concrete information about which operand is being rewritten. No functionality changed, I hope! ;] llvm-svn: 202103
OpenPOWER on IntegriCloud