summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms
Commit message (Collapse)AuthorAgeFilesLines
* Teach SplitBlockPredecessors how to handle landingpad blocks.Philip Reames2015-01-284-42/+29
| | | | | | | | | | Patch by: Igor Laevsky <igor@azulsystems.com> "Currently SplitBlockPredecessors generates incorrect code in case if basic block we are going to split has a landingpad. Also seems like it is fairly common case among it's users to conditionally call either SplitBlockPredecessors or SplitLandingPadPredecessors. Because of this I think it is reasonable to add this condition directly into SplitBlockPredecessors." Differential Revision: http://reviews.llvm.org/D7157 llvm-svn: 227390
* [LPM] Stop using the string based preservation API. It is anChandler Carruth2015-01-283-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | abomination. For starters, this API is incredibly slow. In order to lookup the name of a pass it must take a memory fence to acquire a pointer to the managed static pass registry, and then potentially acquire locks while it consults this registry for information about what passes exist by that name. This stops the world of LLVMs in your process no matter how little they cared about the result. To make this more joyful, you'll note that we are preserving many passes which *do not exist* any more, or are not even analyses which one might wish to have be preserved. This means we do all the work only to say "nope" with no error to the user. String-based APIs are a *bad idea*. String-based APIs that cannot produce any meaningful error are an even worse idea. =/ I have a patch that simply removes this API completely, but I'm hesitant to commit it as I don't really want to perniciously break out-of-tree users of the old pass manager. I'd rather they just have to migrate to the new one at some point. If others disagree and would like me to kill it with fire, just say the word. =] llvm-svn: 227294
* Move EH personality type classification to Analysis/LibCallSemantics.hReid Kleckner2015-01-281-28/+14
| | | | | | | | | | | | | | Summary: Also add enum types for __C_specific_handler and _CxxFrameHandler3 for which we know a few things. Reviewers: majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D7214 llvm-svn: 227284
* SymbolRewriter: allow rewriting with comdatsSaleem Abdulrasool2015-01-271-0/+20
| | | | | | | | | COMDATs must be identically named to the symbol. When support for COMDATs was introduced, the symbol rewriter was not updated, resulting in rewriting failing for symbols which were placed into COMDATs. This corrects the behaviour and adds test cases for this. llvm-svn: 227261
* SymbolRewriter: prevent unnecessary rewriteSaleem Abdulrasool2015-01-271-0/+3
| | | | | | | The rewrite for the pattern based rewrite is unnecessary if the existing name matches the pattern. llvm-svn: 227260
* [SimplifyLibCalls] Don't confuse strcpy_chk for stpcpy_chk.Ahmed Bougacha2015-01-271-10/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This was introduced in a faulty refactoring (r225640, mea culpa): the tests weren't testing the return values, so, for both __strcpy_chk and __stpcpy_chk, we would return the end of the buffer (matching stpcpy) instead of the beginning (for strcpy). The root cause was the prefix "__" being ignored when comparing, which made us always pick LibFunc::stpcpy_chk. Pass the LibFunc::Func directly to avoid this kind of error. Also, make the testcases as explicit as possible to prevent this. The now-useful testcases expose another, entangled, stpcpy problem, with the further simplification. This was introduced in a refactoring (r225640) to match the original behavior. However, this leads to problems when successive simplifications generate several similar instructions, none of which are removed by the custom replaceAllUsesWith. For instance, InstCombine (the main user) doesn't erase the instruction in its custom RAUW. When trying to simplify say __stpcpy_chk: - first, an stpcpy is created (fortified simplifier), - second, a memcpy is created (normal simplifier), but the stpcpy call isn't removed. - third, InstCombine later revisits the instructions, and simplifies the first stpcpy to a memcpy. We now have two memcpys. llvm-svn: 227250
* Teach IRCE to look at branch weights when recognizing range checksSanjoy Das2015-01-271-3/+14
| | | | | | | | | | | Splitting a loop to make range checks redundant is profitable only if the range check "never" fails. Make this fact a part of recognizing a range check -- a branch is a range check only if it is expected to pass (via branch_weights metadata). Differential Revision: http://reviews.llvm.org/D7192 llvm-svn: 227249
* tsan: properly instrument unaligned accessesDmitry Vyukov2015-01-271-1/+22
| | | | | | | | | | | If a memory access is unaligned, emit __tsan_unaligned_read/write callbacks instead of __tsan_read/write. Required to change semantics of __tsan_unaligned_read/write to not do the user memory. But since they were unused (other than through __sanitizer_unaligned_load/store) this is fine. Fixes long standing issue 17: https://code.google.com/p/thread-sanitizer/issues/detail?id=17 llvm-svn: 227231
* [InstCombine] Teach how to fold a select into a cttz/ctlz with the ↵Andrea Di Biagio2015-01-271-0/+63
| | | | | | | | | | | 'is_zero_undef' flag. This patch teaches the Instruction Combiner how to fold a cttz/ctlz followed by a icmp plus select into a single cttz/ctlz with flag 'is_zero_undef' cleared. Added test InstCombine/select-cmp-cttz-ctlz.ll. llvm-svn: 227197
* [sancov] Fix unspecified constructor order between sancov and asan.Evgeniy Stepanov2015-01-271-1/+1
| | | | | | | Sanitizer coverage constructor must run after asan constructor (for each DSO). Bump constructor priority to guarantee that. llvm-svn: 227195
* Migrate SeparateConstOffsetFromGEP to use a Function withEric Christopher2015-01-271-1/+1
| | | | | | getSubtarget. llvm-svn: 227172
* LoopRotate: Don't walk the uses of a ConstantDavid Majnemer2015-01-271-11/+8
| | | | | | | | | | LoopRotate wanted to avoid live range interference by looking at the uses of a Value in the loop latch and seeing if any lied outside of the loop. We would wrongly perform this operation on Constants. This fixes PR22337. llvm-svn: 227171
* Remove unused include.Eric Christopher2015-01-271-1/+0
| | | | llvm-svn: 227170
* [PM] Refactor the core logic to run EarlyCSE over a function into anChandler Carruth2015-01-272-76/+95
| | | | | | | | | | | | | | | | | object that manages a single run of this pass. This was already essentially how it worked. Within the run function, it would point members at *stack local* allocations that were only live for a single run. Instead, it seems much cleaner to have a utility object whose lifetime is clearly bounded by the run of the pass over the function and can use member variables in a more direct way. This also makes it easy to plumb the analyses used into it from the pass and will make it re-usable with the new pass manager. No functionality changed here, its just a refactoring. llvm-svn: 227162
* Commoning of target specific load/store intrinsics in Early CSE.Chad Rosier2015-01-261-29/+111
| | | | | | | Phabricator revision: http://reviews.llvm.org/D7121 Patch by Sanjin Sijaric <ssijaric@codeaurora.org>! llvm-svn: 227149
* SimplifyCFG: Omit range checks for switch lookup tables when default is ↵Hans Wennborg2015-01-261-7/+8
| | | | | | | | | | | unreachable The range check would get optimized away later, but we might as well not emit them in the first place. http://reviews.llvm.org/D6471 llvm-svn: 227126
* SimplifyCFG: don't remove unreachable default switch destinationsHans Wennborg2015-01-261-89/+92
| | | | | | | | | | | | | | | An unreachable default destination can be exploited by other optimizations and allows for more efficient lowering. Both the SDag switch lowering and LowerSwitch can exploit unreachable defaults. Also make TurnSwitchRangeICmp handle switches with unreachable default. This is kind of separate change, but it cannot be tested without the change above, and I don't want to land the change above without this since that would regress other tests. Differential Revision: http://reviews.llvm.org/D6471 llvm-svn: 227125
* Make ConstantFoldTerminator() handle switches with unreachable default.Hans Wennborg2015-01-261-4/+10
| | | | | | | | Tested by Transforms/SimplifyCFG/switch-to-br.ll's @unreachable function. Differential Revision: http://reviews.llvm.org/D6471 llvm-svn: 227124
* SLPVectorizer: fix wrong scheduling of atomic load/stores.Erik Eckstein2015-01-261-1/+12
| | | | | | This fixes PR22306. llvm-svn: 227077
* [PM] General doxygen and comment cleanup for this pass.Chandler Carruth2015-01-241-34/+36
| | | | llvm-svn: 227001
* [PM] Reformat this code with clang-format so that I can use clang-formatChandler Carruth2015-01-241-142/+139
| | | | | | | when refactoring for the new pass manager without introducing too many formatting changes into meaning full diffs. llvm-svn: 227000
* [PM] Port LowerExpectIntrinsic to the new pass manager.Chandler Carruth2015-01-241-20/+28
| | | | | | | | | | | | This just lifts the logic into a static helper function, sinks the legacy pass to be a trivial wrapper of that helper fuction, and adds a trivial wrapper for the new PM as well. Not much to see here. I switched a test case to run in both modes, but we have to strip the dead prototypes separately as that pass isn't in the new pass manager (yet). llvm-svn: 226999
* [PM] Change LowerExpectIntrinsic to actually return true when it hasChandler Carruth2015-01-241-1/+4
| | | | | | | | changed the IR. This is particularly easy as we can just look for the existence of any expect intrinsic at all to know whether we've changed the IR. llvm-svn: 226998
* [PM] Use a more appropriate name for the statistics variable inChandler Carruth2015-01-241-3/+4
| | | | | | | lower-expect, as we don't have 'if's in the IR and we use it for switches as well. llvm-svn: 226997
* [PM] Switch tihs code to use a range based for loop over the function.Chandler Carruth2015-01-241-6/+4
| | | | | | | We can't switch the loop over the instructions because it needs to early-increment the iterator. llvm-svn: 226996
* [PM] Use a SmallVector instead of std::vector to avoid heap allocationsChandler Carruth2015-01-241-7/+6
| | | | | | | | | | | | for small switches, and avoid using a complex loop to set up the weights. We know what the baseline weights will be so we can just resize the vector to contain all that value and clobber the one slot that is likely. This seems much more direct than the previous code that tested at every iteration, and started off by zeroing the vector. llvm-svn: 226995
* [PM] Pull the two helpers for this pass into static functions. There areChandler Carruth2015-01-241-21/+16
| | | | | | | | | no members for them to use. Also, make them accept references as there is no possibility of a null pointer. llvm-svn: 226994
* [PM] Add a basic doxygen comment for this pass.Chandler Carruth2015-01-241-0/+6
| | | | llvm-svn: 226993
* [PM] Clean up the formatting of the LowerExpectIntrinsic pass prior toChandler Carruth2015-01-241-23/+17
| | | | | | refactoring its code. llvm-svn: 226992
* [PM] Move the LowerExpectIntrinsic pass to the Scalar library.Chandler Carruth2015-01-243-1/+1
| | | | | | | | | It was already in the Scalar header and referenced extensively as being in this library, the source file was just in the utils directory for some reason. No actual functionality changed. I noticed as it didn't make sense to add a pass header to the utils headers. llvm-svn: 226991
* [PM] Port instcombine to the new pass manager!Chandler Carruth2015-01-243-143/+65
| | | | | | | | | | | | | | | | | | | | This is exciting as this is a much more involved port. This is a complex, existing transformation pass. All of the core logic is shared between both old and new pass managers. Only the access to the analyses is separate because the actual techniques are separate. This also uses a bunch of different and interesting analyses and is the first time where we need to use an analysis across an IR layer. This also paves the way to expose instcombine utility functions. I've got a static function that implements the core pass logic over a function which might be mildly interesting, but more interesting is likely exposing a routine which just uses instructions *already in* the worklist and combines until empty. I've switched one of my favorite instcombine tests to run with both as well to make sure this keeps working. llvm-svn: 226987
* LowerSwitch: replace unreachable default with popular case destinationHans Wennborg2015-01-231-63/+135
| | | | | | | | | | | | SimplifyCFG currently does this transformation, but I'm planning to remove that to allow other passes, such as this one, to exploit the unreachable default. This patch takes care to keep track of what case values are unreachable even after the transformation, allowing for more efficient lowering. Differential Revision: http://reviews.llvm.org/D6697 llvm-svn: 226934
* Revert "Don't remove a landing pad if the invoke requires a table entry."Reid Kleckner2015-01-221-17/+3
| | | | | | | | | | | | This reverts commit r176827. Björn Steinbrink pointed out that this didn't actually fix the bug (PR15555) it was attempting to fix. With this reverted, we can now remove landingpad cleanups that immediately resume unwinding, converting the invoke to a call. llvm-svn: 226850
* Silencing a -Wsign-compare warning (all uses of this constant are within ↵Aaron Ballman2015-01-221-1/+1
| | | | | | unsigned expressions anyway); NFC. llvm-svn: 226826
* [ASan/Win] Move the shadow to 0x30000000Timur Iskhodzhanov2015-01-221-1/+1
| | | | llvm-svn: 226809
* [NFC] Introduce a 'struct Range' for IRCESanjoy Das2015-01-221-17/+27
| | | | | | | | | Use the struct instead of a std::pair<Value *, Value *>. This makes a Range an obviously immutable object, and we can now assert that a range is well-typed (Begin->getType() == End->getType()) on its construction. llvm-svn: 226804
* Fix crashes in IRCE caused by mismatched typesSanjoy Das2015-01-221-7/+35
| | | | | | | | | | | | | | | There are places where the inductive range check elimination pass depends on two llvm::Values or llvm::SCEVs to be of the same llvm::Type when they do not need to be. This patch relaxes those restrictions (by bailing out of the optimization if the types mismatch), and adds test cases to trigger those paths. These issues were found by bootstrapping clang with IRCE running in the -O3 pass ordering. Differential Revision: http://reviews.llvm.org/D7082 llvm-svn: 226793
* SLPVectorizer: add a second limit for the number of alias checks.Erik Eckstein2015-01-221-21/+49
| | | | | | | | Even with the current limit on the number of alias checks, the containing loop has quadratic complexity. This begins to hurt for blocks containing > 1K load/store instructions. This commit introduces a limit for the loop count. It reduces the runtime for such very large blocks. llvm-svn: 226792
* Fixed a bug in masked load/store in reversed loop.Elena Demikhovsky2015-01-221-0/+2
| | | | | | | | | Added a test. The bug was submitted to bugzilla: http://llvm.org/bugs/show_bug.cgi?id=22225 llvm-svn: 226791
* [PM] Rename InstCombine.h to InstCombineInternal.h in preparation forChandler Carruth2015-01-2214-16/+21
| | | | | | | | | | | | | | | | creating a non-internal header file for the InstCombine pass. I thought about calling this InstCombiner.h or in some way more clearly associating it with the InstCombiner clas that it is primarily defining, but there are several other utility interfaces defined within this for InstCombine. If, in the course of refactoring, those end up moving elsewhere or going away, it might make more sense to make this the combiner's header alone. Naturally, this is a bikeshed to a certain degree, so feel free to lobby for a different shade of paint if this name just doesn't suit you. llvm-svn: 226783
* [canonicalize] Teach InstCombine to canonicalize loads which are onlyChandler Carruth2015-01-221-0/+29
| | | | | | | | | | | | | | | | | | | | | | | ever stored to always use a legal integer type if one is available. Regardless of whether this particular type is good or bad, it ensures we don't get weird differences in generated code (and resulting performance) from "equivalent" patterns that happen to end up using a slightly different type. After some discussion on llvmdev it seems everyone generally likes this canonicalization. However, there may be some parts of LLVM that handle it poorly and need to be fixed. I have at least verified that this doesn't impede GVN and instcombine's store-to-load forwarding powers in any obvious cases. Subtle cases are exactly what we need te flush out if they remain. Also note that this IR pattern should already be hitting LLVM from Clang at least because it is exactly the IR which would be produced if you used memcpy to copy a pointer or floating point between memory instead of a variable. llvm-svn: 226781
* [canonicalize] Move a helper function further up the file so it can beChandler Carruth2015-01-221-47/+47
| | | | | | used earlier. NFC. llvm-svn: 226777
* [canonicalization] Refactor how we create new stores into a helperChandler Carruth2015-01-211-38/+48
| | | | | | | function. This is a bit tidier anyways and will make a subsquent patch simpler as I want to add another case to this combine. llvm-svn: 226746
* DebugInfo: Use distinct inlinedAt MDLocations to avoid separate inlined ↵David Blaikie2015-01-211-13/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | calls being coalesced When two calls from the same MDLocation are inlined they currently get treated as one inlined function call (creating difficulty debugging, duplicate variables, etc). Clang worked around this by including column information on inline calls which doesn't address LTO inlining or calls to the same function from the same line and column (such as through a macro). It also didn't address ctor and member function calls. By making the inlinedAt locations distinct, every call site has an explicitly distinct location that cannot be coalesced with any other call. This can produce linearly (2x in the worst case where every call is inlined and the call instruction has a non-call instruction at the same location) more debug locations. Any increase beyond that are in cases where the Clang workaround was insufficient and the new scheme is creating necessary distinct nodes that were being erroneously coalesced previously. After this change to LLVM the incomplete workarounds in Clang. That should reduce the number of debug locations (in a build without column info, the default on Darwin, not the default on Linux) by not creating pseudo-distinct locations for every call to an inline function. (oh, and I made the inlined-at chain rebuilding iterative instead of recursive because I was having trouble wrapping my head around it the way it was - open to discussion on the right design for that function (including going back to a recursive solution)) llvm-svn: 226736
* InstCombine: Don't strip bitcasts off of callsites marked 'thunk'David Majnemer2015-01-211-0/+4
| | | | | | | The return type of a thunk is meaningless, we just want the arguments and return value to be forwarded. llvm-svn: 226708
* [msan] Update origin for the entire destination range on memory store.Evgeniy Stepanov2015-01-211-9/+49
| | | | | | | | | Previously we always stored 4 bytes of origin at the destination address even for 8-byte (and longer) stores. This should fix rare missing, or incorrect, origin stacks in MSan reports. llvm-svn: 226658
* [PM] Refactor the InstCombiner interface to use an external worklist.Chandler Carruth2015-01-212-211/+222
| | | | | | | | | | | | | | | | | | | | | | | | | Because in its primary function pass the combiner is run repeatedly over the same function until doing so produces no changes, it is essentially to not re-allocate the worklist. However, as a utility, the more common pattern would be to put a limited set of instructions in the worklist rather than the entire function body. That is also the more likely pattern when used by the new pass manager. The result is a very light weight combiner that does the visiting with a separable worklist. This can then be wrapped up in a helper function for users that want a combiner utility, or as I have here it can be wrapped up in a pass which manages the iterations used when combining an entire function's instructions. Hopefully this removes some of the worst of the interface warts that became apparant with the last patch here. However, there is clearly more work. I've again left some FIXMEs for the most egregious. The ones that stick out to me are the exposure of the worklist and IR builder as public members, and the use of pointers rather than references. However, fixing these is likely to be much more mechanical and less interesting so I didn't want to touch them in this patch. llvm-svn: 226655
* [PM] Simplify (ha! ha!) the way that instcombine calls theChandler Carruth2015-01-213-9/+6
| | | | | | | | | | | | SimplifyLibCalls utility by sinking it into the specific call part of the combiner. This will avoid us needing to do any contortions to build this object in a subsequent refactoring I'm doing and seems generally better factored. We don't need this utility everywhere and it carries no interesting state so we might as well build it on demand. llvm-svn: 226654
* [PM] Replace an abuse of inheritance to override a single function withChandler Carruth2015-01-212-27/+15
| | | | | | | | | | | | | a more direct approach: a type-erased glorified function pointer. Now we can pass a function pointer into this for the easy case and we can even pass a lambda into it in the interesting case in the instruction combiner. I'll be using this shortly to simplify the interfaces to InstCombiner, but this helps pave the way and seems like a better design for the libcall simplifier utility. llvm-svn: 226640
* [PM] Separate the InstCombiner from its pass.Chandler Carruth2015-01-202-49/+79
| | | | | | | | | | | | | | | | | | | | This creates a small internal pass which runs the InstCombiner over a function. This is the hard part of porting InstCombine to the new pass manager, as at this point none of the code in InstCombine has access to a Pass object any longer. The resulting interface for the InstCombiner is pretty terrible. I'm not planning on leaving it that way. The key thing missing is that we need to separate the worklist from the combiner a touch more. Once that's done, it should be possible for *any* part of LLVM to just create a worklist with instructions, populate it, and then combine it until empty. The pass will just be the (obvious and important) special case of doing that for an entire function body. For now, this is the first increment of factoring to make all of this work. llvm-svn: 226618
OpenPOWER on IntegriCloud