summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms
Commit message (Collapse)AuthorAgeFilesLines
* Teach LoopVectorize about address space sizesMatt Arsenault2013-08-221-1/+2
| | | | llvm-svn: 188980
* Fixed typo.Michael Gottesman2013-08-211-1/+1
| | | | llvm-svn: 188957
* Removed trailing whitespace.Michael Gottesman2013-08-211-13/+13
| | | | llvm-svn: 188956
* No functionality change.Yunzhong Gao2013-08-211-2/+2
| | | | | | Replace "(255 & value)" with "(0xFF & value)" to improve clarity. llvm-svn: 188941
* Teach InstCombine about address spacesMatt Arsenault2013-08-212-21/+33
| | | | llvm-svn: 188926
* Use attribute helper functionMatt Arsenault2013-08-211-2/+1
| | | | llvm-svn: 188916
* Fix typoMatt Arsenault2013-08-211-1/+1
| | | | llvm-svn: 188915
* Move registering the execution of a basic block to the beginning rather than ↵Bill Wendling2013-08-201-7/+7
| | | | | | | | | | | | | | | | | the end. There are situations which can affect the correctness (or at least expectation) of the gcov output. For instance, if a call to __gcov_flush() occurs within a block before the execution count is registered and then the program aborts in some way, then that block will not be marked as executed. This is not normally what the user expects. If we move the code that's registering when a block is executed to the beginning, we can catch these types of situations. PR16893 llvm-svn: 188849
* SLPVectorizer: Fix invalid iterator errorsArnold Schwaighofer2013-08-201-13/+51
| | | | | | | | | | | Update iterator when the SLP vectorizer changes the instructions in the basic block by restarting the traversal of the basic block. Patch by Yi Jiang! Fixes PR 16899. llvm-svn: 188832
* Add a llvm.copysign intrinsicHal Finkel2013-08-191-0/+5
| | | | | | | | | | | | | | | | | | | | | This adds a llvm.copysign intrinsic; We already have Libfunc recognition for copysign (which is turned into the FCOPYSIGN SDAG node). In order to autovectorize calls to copysign in the loop vectorizer, we need a corresponding intrinsic as well. In addition to the expected changes to the language reference, the loop vectorizer, BasicTTI, and the SDAG builder (the intrinsic is transformed into an FCOPYSIGN node, just like the function call), this also adds FCOPYSIGN to a few lists in LegalizeVector{Ops,Types} so that vector copysigns can be expanded. In TargetLoweringBase::initActions, I've made the default action for FCOPYSIGN be Expand for vector types. This seems correct for all in-tree targets, and I think is the right thing to do because, previously, there was no way to generate vector-values FCOPYSIGN nodes (and most targets don't specify an action for vector-typed FCOPYSIGN). llvm-svn: 188728
* Use pop_back_val() instead of both back() and pop_back().Jakub Staszak2013-08-191-2/+1
| | | | llvm-svn: 188723
* Teach InstCombine visitGetElementPtr about address spacesMatt Arsenault2013-08-193-20/+26
| | | | llvm-svn: 188721
* Cleanup visitGetElementPtr to make address space change easierMatt Arsenault2013-08-191-11/+13
| | | | llvm-svn: 188720
* commonPointerCast cleanups to make address space change easierMatt Arsenault2013-08-191-5/+11
| | | | llvm-svn: 188719
* Revert non-test parts of r188507Matt Arsenault2013-08-191-1/+9
| | | | | | Re-add the inboundsless tests I didn't add originally llvm-svn: 188710
* Introduce SpecialCaseList::isIn overload for GlobalAliases.Peter Collingbourne2013-08-191-2/+14
| | | | | | Differential Revision: http://llvm-reviews.chandlerc.com/D1437 llvm-svn: 188688
* Adds missing TLI check for library simplification ofMichael Kuperstein2013-08-191-3/+6
| | | | | | | * pow(x, 0.5) -> fabs(sqrt(x)) * pow(2.0, x) -> exp2(x) llvm-svn: 188656
* Remove SpecialCaseList::findCategory.Peter Collingbourne2013-08-191-35/+0
| | | | | | It turned out that I didn't need this for DFSan. llvm-svn: 188646
* PR 16899: Do not modify the basic block using the iterator, but keep theJoerg Sonnenberger2013-08-171-4/+6
| | | | | | | | next value. This avoids crashes due to invalidation. Patch by Joey Gouly. llvm-svn: 188605
* InstCombine: Use isAllOnesValue() instead of explicit -1.Jim Grosbach2013-08-161-1/+1
| | | | llvm-svn: 188563
* InstCombine: Simplify if(x!=0 && x!=-1).Jim Grosbach2013-08-161-1/+6
| | | | | | | | | | | When both constants are positive or both constants are negative, InstCombine already simplifies comparisons like this, but when it's exactly zero and -1, the operand sorting ends up reversed and the pattern fails to match. Handle that special case. Follow up for rdar://14689217 llvm-svn: 188512
* Don't do FoldCmpLoadFromIndexedGlobal for non inbounds GEPsMatt Arsenault2013-08-151-9/+2
| | | | | | | This path wasn't tested before without a datalayout, so add some more tests and re-run with and without one. llvm-svn: 188507
* Fix spellingMatt Arsenault2013-08-151-2/+2
| | | | llvm-svn: 188506
* Fixing a corner-case bug in strchr and strrchr lib call optimizations whereYunzhong Gao2013-08-151-2/+2
| | | | | | | | | the input character is not converted to char before comparing with zero. The patch was discussed in this thread: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130812/184069.html llvm-svn: 188489
* DataFlowSanitizer: Add a debugging feature to help us track nonzero labels.Peter Collingbourne2013-08-151-2/+48
| | | | | | | | | | | | | | | | | | Summary: When the -dfsan-debug-nonzero-labels parameter is supplied, the code is instrumented such that when a call parameter, return value or load produces a nonzero label, the function __dfsan_nonzero_label is called. The idea is that a debugger breakpoint can be set on this function in a nominally label-free program to help identify any bugs in the instrumentation pass causing labels to be introduced. Reviewers: eugenis CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1405 llvm-svn: 188472
* Fix small typo: s/succ/Succ/Mark Lacey2013-08-141-1/+1
| | | | llvm-svn: 188415
* DataFlowSanitizer: Instrumentation for memset.Peter Collingbourne2013-08-141-1/+22
| | | | | | Differential Revision: http://llvm-reviews.chandlerc.com/D1395 llvm-svn: 188412
* DataFlowSanitizer: greylist is now ABI list.Peter Collingbourne2013-08-141-96/+271
| | | | | | | | | | | | | | | | | | | | | | | | | This replaces the old incomplete greylist functionality with an ABI list, which can provide more detailed information about the ABI and semantics of specific functions. The pass treats every function in the "uninstrumented" category in the ABI list file as conforming to the "native" (i.e. unsanitized) ABI. Unless the ABI list contains additional categories for those functions, a call to one of those functions will produce a warning message, as the labelling behaviour of the function is unknown. The other supported categories are "functional", "discard" and "custom". - "discard" -- This function does not write to (user-accessible) memory, and its return value is unlabelled. - "functional" -- This function does not write to (user-accessible) memory, and the label of its return value is the union of the label of its arguments. - "custom" -- Instead of calling the function, a custom wrapper __dfsw_F is called, where F is the name of the function. This function may wrap the original function or provide its own implementation. Differential Revision: http://llvm-reviews.chandlerc.com/D1345 llvm-svn: 188402
* Fix a really terrifying but improbable bug in mem2reg. If you have seenChandler Carruth2013-08-141-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | extremely subtle miscompilations (such as a load getting replaced with the value stored *below* the load within a basic block) related to promoting an alloca to an SSA value, there is the dim possibility that you hit this. Please let me know if you won this unfortunate lottery. The first half of mem2reg's core logic (as it is used both in the standalone mem2reg pass and in SROA) builds up a mapping from 'Instruction *' to the index of that instruction within its basic block. This allows quickly establishing which store dominate a particular load even for large basic blocks. We cache this information throughout the run of mem2reg over a function in order to amortize the cost of computing it. This is not in and of itself a strange pattern in LLVM. However, it introduces a very important constraint: absolutely no instruction can be deleted from the program without updating the mapping. Otherwise a newly allocated instruction might get the same pointer address, and then end up with a wrong index. Yes, LLVM routinely suffers from a *single threaded* variant of the ABA problem. Most places in LLVM don't find avoiding this an imposition because they don't both delete and create new instructions iteratively, but mem2reg *loves* to do this... All the time. Fortunately, the mem2reg code was really careful about updating this cache to handle this eventuallity... except when it comes to the debug declare intrinsic. Oops. The fix is to invalidate that pointer in the cache when we delete it, the same as we do when deleting alloca instructions and other instructions. I've also caused the same bug in new code while working on a fix to PR16867, so this seems to be a really unfortunate pattern. Hopefully in subsequent patches the deletion of dead instructions can be consolidated sufficiently to make it less likely that we'll see future occurences of this bug. Sorry for not having a test case, but I have literally no idea how to reliably trigger this kind of thing. It may be single-threaded, but it remains an ABA problem. It would require a really amazing number of stars to align. llvm-svn: 188367
* Fix always creating GEP with i32 indicesMatt Arsenault2013-08-142-10/+16
| | | | | | | | | | | | | | | | Use the pointer size if datalayout is available. Use i64 if it's not, which is consistent with what other places do when the pointer size is unknown. The test doesn't really test this in a useful way since it will be transformed to that later anyway, but this now tests it for non-zero arrays and when datalayout isn't available. The cases in visitGetElementPtrInst should save an extra re-visit to the newly created GEP since it won't need to cleanup after itself. llvm-svn: 188339
* Use type helper functions instead of castMatt Arsenault2013-08-142-11/+8
| | | | llvm-svn: 188338
* Use array initializer, space around operatorMatt Arsenault2013-08-141-5/+3
| | | | llvm-svn: 188337
* BBVectorize: Add initial stores to the write set when tracking usesHal Finkel2013-08-131-0/+9
| | | | | | | | | | | | | | | | When computing the use set of a store, we need to add the store to the write set prior to iterating over later instructions. Otherwise, if there is a later aliasing load of that store, that load will not be tagged as a use, and bad things will happen. trackUsesOfI still adds later dependent stores of an instruction to that instruction's write set, but it never sees the original instruction, and so when tracking uses of a store, the store must be added to the write set by the caller. Fixes PR16834. llvm-svn: 188329
* Revert r187191, which broke opt -mem2reg on the testcases included in PR16867.Nick Lewycky2013-08-134-252/+114
| | | | | | | | | | | | However, opt -O2 doesn't run mem2reg directly so nobody noticed until r188146 when SROA started sending more things directly down the PromoteMemToReg path. In order to revert r187191, I also revert dependent revisions r187296, r187322 and r188146. Fixes PR16867. Does not add the testcases from that PR, but both of them should get added for both mem2reg and sroa when this revert gets unreverted. llvm-svn: 188327
* dfsan: fix lint warningsDmitry Vyukov2013-08-131-2/+2
| | | | llvm-svn: 188293
* Also remove logic in LateVectorizeArnold Schwaighofer2013-08-131-1/+1
| | | | llvm-svn: 188285
* Remove logic that decides whether to vectorize or not depending on O-levelsArnold Schwaighofer2013-08-131-1/+1
| | | | | | I have moved this logic into clang and opt. llvm-svn: 188281
* Reapply r188119 now that the bug it exposed is fixed.Peter Collingbourne2013-08-122-172/+140
| | | | llvm-svn: 188217
* DataFlowSanitizer: fix a use-after-free. Spotted by libgmalloc.Peter Collingbourne2013-08-121-1/+4
| | | | llvm-svn: 188216
* Move stack protector names to the same place.Bill Wendling2013-08-121-5/+3
| | | | llvm-svn: 188198
* Fix PR16797 - Support PHINodes with multiple inputs from the same basic block.Nadav Rotem2013-08-121-0/+11
| | | | | | | Do not generate new vector values for the same entries because we know that the incoming values from the same block must be identical. llvm-svn: 188185
* Remove unused SpecialCaseList constructorsAlexey Samsonov2013-08-121-20/+0
| | | | llvm-svn: 188171
* Add SpecialCaseList::createOrDie() factory and use it in sanitizer passesAlexey Samsonov2013-08-125-7/+14
| | | | llvm-svn: 188169
* Introduce factory methods for SpecialCaseListAlexey Samsonov2013-08-121-10/+43
| | | | | | | | | | | | | | | | | | | | Summary: Doing work in constructors is bad: this change suggests to call SpecialCaseList::create(Path, Error) instead of "new SpecialCaseList(Path)". Currently the latter may crash with report_fatal_error, which is undesirable - sometimes we want to report the error to user gracefully - for example, if he provides an incorrect file as an argument of Clang's -fsanitize-blacklist flag. Reviewers: pcc Reviewed By: pcc CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1327 llvm-svn: 188156
* Fix big-endian handling of integer-to-vector bitcasts in InstCombineRichard Sandiford2013-08-121-20/+32
| | | | | | | | | | These functions used to assume that the lsb of an integer corresponds to vector element 0, whereas for big-endian it's the other way around: the msb is in the first element and the lsb is in the last element. Fixes MultiSource/Benchmarks/mediabench/gsm/toast for z. llvm-svn: 188155
* Re-instate r187323 which fast-tracks promotable allocas as soon as theChandler Carruth2013-08-111-12/+81
| | | | | | | | | | | | | | | | | | | | | | | | | SROA-based analysis has enough information. This should work now that both mem2reg *and* the SSAUpdater-based AllocaPromoter have been updated to be able to promote the types of allocas that the SROA analysis detects. I've included tests for the AllocaPromoter that were only possible to write once we fast-tracked promotable allocas without rewriting them. This includes a test both for r187347 and r188145. Original commit log for r187323: """ Now that mem2reg understands how to cope with a slightly wider set of uses of an alloca, we can pre-compute promotability while analyzing an alloca for splitting in SROA. That lets us short-circuit the common case of a bunch of trivially promotable allocas. This cuts 20% to 30% off the run time of SROA for typical frontend-generated IR sequneces I'm seeing. It gets the new SROA to within 20% of ScalarRepl for such code. My current benchmark for these numbers is PR15412, but it fits the general pattern of IR emitted by Clang so it should be widely applicable. """ llvm-svn: 188146
* Finish fixing the SSAUpdater-based AllocaPromoter strategy in SROA to cope withChandler Carruth2013-08-111-2/+23
| | | | | | | | | | | | | | | | | | | | the more general set of patterns that are now handled by mem2reg and that we can detect quickly while doing SROA's initial analysis. Notably, this allows it to promote through no-op bitcast and GEP sequences. A core part of the SSAUpdater approach is the ability to test whether a particular instruction is part of the set being promoted. Testing this becomes significantly more complex in the world where the operand to every load and store isn't the alloca itself. I ended up using the approach of walking up the def-chain until we find the alloca. I benchmarked this against keeping a set of pointer operands and keeping a set of the loads and stores we care about, and this one seemed faster although the difference was very small. No test case yet because currently the rewriting always "fixes" the inputs to not require this. The next patch which re-enables early promotion of easy cases in SROA will include a test case that specifically exercises this aspect of the alloca promoter. llvm-svn: 188145
* Reformat some bits of AllocaPromoter and simplify the name and type ofChandler Carruth2013-08-111-21/+20
| | | | | | | | | our visiting datastructures in the AllocaPromoter/SSAUpdater path of SROA. Also shift the order if clears around to be more consistent. No functionality changed here, this is just a cleanup. llvm-svn: 188144
* Revert r188119 "Kill some duplicated code for removing unreachable BBs."Arnold Schwaighofer2013-08-102-140/+172
| | | | | | | | | | | | | | It is breaking builbots with libgmalloc enabled on Mac OS X. $ cd llvm ; mkdir release ; cd release $ ../configure --enable-optimized —prefix=$PWD/install $ make $ make check $ Release+Asserts/bin/llvm-lit -v --param use_gmalloc=1 --param \ gmalloc_path=/usr/lib/libgmalloc.dylib \ ../test/Instrumentation/DataFlowSanitizer/args-unreachable-bb.ll llvm-svn: 188142
* [objc-arc] Track if we encountered an additive overflow while computing ↵Michael Gottesman2013-08-091-8/+53
| | | | | | | | | | | {TopDown,BottomUp}PathCounts and do nothing if it occurred. I fixed the aforementioned problems that came up on some of the linux boxes. Major thanks to Nick Lewycky for his help debugging! rdar://14590914 llvm-svn: 188122
OpenPOWER on IntegriCloud