summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms
Commit message (Collapse)AuthorAgeFilesLines
...
* [Layering] Move DIBuilder.h into the IR library where its implementationChandler Carruth2014-03-068-8/+8
| | | | | | already lives. llvm-svn: 203038
* LoopVectorizer: Preserve fast-math flagsArnold Schwaighofer2014-03-051-5/+21
| | | | | | Fixes PR19045. llvm-svn: 203008
* [Layering] Move DebugLoc.h into the IR library. The implementationChandler Carruth2014-03-051-1/+1
| | | | | | | | | | | already lived there and it is where it belongs -- this is the in-memory debug location representation. This is just cleanup -- Modules can actually cope with this, but that doesn't make it right. After chatting with folks that have out-of-tree stuff, going ahead and moving the rest of the headers seems preferable. llvm-svn: 202960
* [C++11] Make this interface accept const Use pointers and use overrideChandler Carruth2014-03-052-3/+3
| | | | | | | | 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] Replace OwningPtr::take() with OwningPtr::release().Ahmed Charles2014-03-051-1/+1
| | | | llvm-svn: 202957
* [C++11] Add 'override' keyword to virtual methods that override their base ↵Craig Topper2014-03-0584-281/+328
| | | | | | class. llvm-svn: 202953
* [Modules] Move the ConstantRange class into the IR library. This isChandler Carruth2014-03-043-3/+3
| | | | | | | | | | a bit surprising, as the class is almost entirely abstracted away from any particular IR, however it encodes the comparsion predicates which mutate ranges as ICmp predicate codes. This is reasonable as they're used for both instructions and constants. Thus, it belongs in the IR library with instructions and constants. llvm-svn: 202838
* [Modules] Move the PredIteratorCache into the IR library -- it isChandler Carruth2014-03-042-2/+2
| | | | | | hardcoded to use IR BasicBlocks. llvm-svn: 202835
* [Modules] Move the NoFolder into the IR library as it createsChandler Carruth2014-03-041-1/+1
| | | | | | instructions. llvm-svn: 202834
* [Modules] Move the TargetFolder into the Analysis library. Historically,Chandler Carruth2014-03-042-2/+2
| | | | | | | | | this would have been required because of the use of DataLayout, but that has moved into the IR proper. It is still required because this folder uses the constant folding in the analysis library (which uses the datalayout) as the more aggressive basis of its folder. llvm-svn: 202832
* [Modules] Move CFG.h to the IR library as it defines graph traits overChandler Carruth2014-03-0424-24/+24
| | | | | | IR types. llvm-svn: 202827
* [Modules] Move ValueMap to the IR library. While this class does notChandler Carruth2014-03-042-2/+2
| | | | | | | | | | | | directly care about the Value class (it is templated so that the key can be any arbitrary Value subclass), it is in fact concretely tied to the Value class through the ValueHandle's CallbackVH interface which relies on the key type being some Value subclass to establish the value handle chain. Ironically, the unittest is already in the right library. llvm-svn: 202824
* [Modules] Move ValueHandle into the IR library where Value itself lives.Chandler Carruth2014-03-0411-11/+11
| | | | | | | | | | | 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-0415-15/+15
| | | | | | obviously is coupled to the IR. llvm-svn: 202818
* [Modules] Move CallSite into the IR library where it belogs. It isChandler Carruth2014-03-0416-16/+16
| | | | | | | 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-047-7/+7
| | | | | | | | | 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-049-9/+9
| | | | | | | | | | | | | 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
* [cleanup] Re-sort all the includes with utils/sort_includes.py.Chandler Carruth2014-03-041-2/+2
| | | | llvm-svn: 202811
* Pass to emit DWARF path discriminators.Diego Novillo2014-03-033-0/+219
| | | | | | | | | | | | | | | | DWARF discriminators are used to distinguish multiple control flow paths on the same source location. When this happens, instructions across basic block boundaries will share the same debug location. This pass detects this situation and creates a new lexical scope to one of the two instructions. This lexical scope is a child scope of the original and contains a new discriminator value. This discriminator is then picked up from MCObjectStreamer::EmitDwarfLocDirective to be written on the object file. This fixes http://llvm.org/bugs/show_bug.cgi?id=18270. llvm-svn: 202752
* [C++11] Use std::tie to simplify compare operators.Benjamin Kramer2014-03-032-21/+6
| | | | | | 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
* [msan] Handle X86 SIMD bitshift intrinsics.Evgeniy Stepanov2014-03-031-0/+119
| | | | llvm-svn: 202712
* [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-023-5/+5
| | | | | | 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-0219-48/+50
| | | | | | 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-016-110/+37
| | | | | | | | of boilerplate. No intended functionality change. llvm-svn: 202588
* Reflow isProfitableToMakeFastCCReid Kleckner2014-02-281-1/+2
| | | | llvm-svn: 202555
* [asan] fix a pair of silly typosKostya Serebryany2014-02-271-2/+2
| | | | llvm-svn: 202391
* [asan] disable asan-detect-invalid-pointer-pair (was enabled by mistake)Kostya Serebryany2014-02-271-1/+1
| | | | llvm-svn: 202390
* [asan] *experimental* implementation of invalid-pointer-pair detector (finds ↵Kostya Serebryany2014-02-271-0/+56
| | | | | | when two unrelated pointers are compared or subtracted). This implementation has both false positives and false negatives and is not tuned for performance. A bug report for a proper implementation will follow. llvm-svn: 202389
* GlobalOpt: Apply fastcc to internal x86_thiscallcc functionsReid Kleckner2014-02-261-5/+14
| | | | | | | | | | We should apply fastcc whenever profitable. We can expand this list, but there are lots of conventions with performance implications that we don't want to change. Differential Revision: http://llvm-reviews.chandlerc.com/D2705 llvm-svn: 202293
* 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-2530-43/+83
| | | | | | | 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
OpenPOWER on IntegriCloud