summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis
Commit message (Collapse)AuthorAgeFilesLines
...
* [ValueTracking] Use guards to prove non-nullness of a valueSanjoy Das2016-05-101-9/+11
| | | | | | | | | | Reviewers: apilipenko, majnemer, reames Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D20044 llvm-svn: 269008
* [BasicAA] Guard intrinsics don't write to memorySanjoy Das2016-05-101-4/+32
| | | | | | | | | | | | | | | | Summary: The idea is very close to what we do for assume intrinsics: we mark the guard intrinsics as writing to arbitrary memory to maintain control dependence, but under the covers we teach AA that they do not mod any particular memory location. Reviewers: chandlerc, hfinkel, gbiv, reames Subscribers: george.burgess.iv, mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D19575 llvm-svn: 269007
* [SCEVExpander] Clang format expressions; NFCSanjoy Das2016-05-101-17/+16
| | | | | | The boolean expressions are somewhat hard to read otherwise. llvm-svn: 268998
* [SCEV] Use guards to prove predicatesSanjoy Das2016-05-101-3/+44
| | | | | | | | | We can use calls to @llvm.experimental.guard to prove predicates, relying on the fact that in all locations domianted by a call to @llvm.experimental.guard the predicate it is guarding is known to be true. llvm-svn: 268997
* [LV] Hint at the new loop distribution pragma in optimization remarkAdam Nemet2016-05-091-2/+6
| | | | | | | | | | When we encounter unsafe memory dependencies, loop distribution could help. Even though, the diagnostics is in LAA, it's only currently emitted in the vectorizer. llvm-svn: 268987
* [Inliner] don't assume that a Constant alloca size is a ConstantInt (PR27277)Sanjay Patel2016-05-091-4/+4
| | | | | | Differential Revision: http://reviews.llvm.org/D20077 llvm-svn: 268980
* DivergenceAnalysis: Fix crash with no return blocksMatt Arsenault2016-05-091-1/+7
| | | | | | The post dominator tree does not have a root node in this case. llvm-svn: 268933
* fix spelling; NFCSanjay Patel2016-05-091-2/+2
| | | | llvm-svn: 268929
* [VectorUtils] Query number of sign bits to allow more truncationsJames Molloy2016-05-091-4/+14
| | | | | | When deciding if a vector calculation can be done in a smaller bitwidth, use sign bit information from ValueTracking to add more information and allow more truncations. llvm-svn: 268921
* [X86] Promote several single precision FP libcalls on WindowsDavid Majnemer2016-05-081-0/+2
| | | | | | | | | | | | A number of libcalls don't exist in any particular lib but are, instead, defined in math.h as inline functions (even in C mode!). Don't rely on their existence when lowering @llvm.{cos,sin,floor,..}.f32, promote them instead. N.B. We had logic to handle FREM but were missing out on a number of others. This change generalizes the FREM handling. llvm-svn: 268875
* [ValueTracking] Hoist some computation out of a loop; NFCSanjoy Das2016-05-071-20/+11
| | | | | | There is no need to match the comparison instruction repeatedly. llvm-svn: 268836
* Clean up comment; NFCSanjoy Das2016-05-071-1/+1
| | | | llvm-svn: 268835
* Delete trailing whitespace; NFCSanjoy Das2016-05-071-8/+8
| | | | llvm-svn: 268834
* ThinLTO: fix assertion and refactor check for hidden use from inline ASM in ↵Mehdi Amini2016-05-061-31/+43
| | | | | | | | | | | a helper function This test was crashing, and currently it breaks bootstrapping clang with debuginfo Differential Revision: http://reviews.llvm.org/D20008 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 268715
* [LAA] Fix confusing debug messageAdam Nemet2016-05-051-1/+1
| | | | | | | | This message used to be correct, when all we cared about was whether the dependence was safe (i.e. NoDep) or unsafe. With the current more precise characterization, this is a forward dep. llvm-svn: 268695
* [PM] port Branch Frequency Analaysis pass to new PMXinliang David Li2016-05-051-0/+27
| | | | llvm-svn: 268687
* [ValueTracking] Early exit when further analysis won't be fruitful.Chad Rosier2016-05-051-15/+30
| | | | | | | This should have NFC in the context of codegen, but may have positive implications on compile-time. llvm-svn: 268651
* [ValueTracking] Improve isImpliedCondition for matching LHS and Imm RHSs.Chad Rosier2016-05-051-0/+29
| | | | llvm-svn: 268636
* [PM] Port Branch Probability Analysis pass to the new pass manager.Xinliang David Li2016-05-051-0/+17
| | | | | | Differential Revision: http://reviews.llvm.org/D19839 llvm-svn: 268601
* [ConstantFolding, ValueTracking] Fold constants involving bitcasts of ↵David Majnemer2016-05-042-9/+31
| | | | | | | | | | | | | | | | | ConstantVector We assumed that ConstantVectors would be rather uninteresting from the perspective of analysis. However, this is not the case due to a quirk of how LLVM handles vectors of i1. Vectors of i1 are not ConstantDataVectors like vectors of i8, i16, i32 or i64 because i1's SizeInBits differs from it's StoreSizeInBytes. This leads to it being categorized as a ConstantVector instead of a ConstantDataVector. Instead, treat ConstantVector more uniformly. This fixes PR27591. llvm-svn: 268479
* PM: Check that loop passes preserve a basic set of analysesJustin Bogner2016-05-031-0/+19
| | | | | | | | | | | A loop pass that didn't preserve this entire set of passes wouldn't play well with other loop passes, since these are generally a basic requirement to do any interesting transformations to a loop. Adds a helper to get the set of analyses a loop pass should preserve, and checks that any loop pass we run satisfies the requirement. llvm-svn: 268444
* [SCEV] Tweak the output format and content of -analyzeSanjoy Das2016-05-031-3/+18
| | | | | | | | | | | | | In the "LoopDispositions:" section: - Instead of printing out a list, print out a "dictionary" to make it obvious by inspection which disposition is for which loop. This is just a cosmetic change. - Print dispositions for parent _and_ sibling loops. I will use this to write a test case. llvm-svn: 268405
* Fold compares irrespective of whether allocation can be elidedAnna Thomas2016-05-032-6/+30
| | | | | | | | | | | | | | | | | | | Summary When a non-escaping pointer is compared to a global value, the comparison can be folded even if the corresponding malloc/allocation call cannot be elided. We need to make sure the global value is not null, since comparisons to null cannot be folded. In future, we should also handle cases when the the comparison instruction dominates the pointer escape. Reviewers: sanjoy Subscribers s.egerton, llvm-commits Differential Revision: http://reviews.llvm.org/D19549 llvm-svn: 268390
* [LoopUnroll] Unroll loops which have exit blocks to EH padsDavid Majnemer2016-05-031-16/+3
| | | | | | | | | | | | | We were overly cautious in our analysis of loops which have invokes which unwind to EH pads. The loop unroll transform is safe because it only clones blocks in the loop body, it does not try to split critical edges involving EH pads. Instead, move the necessary safety check to LoopUnswitch. N.B. The safety check for loop unswitch is covered by an existing test which fails without it. llvm-svn: 268357
* [LVI] Add an API to LazyValueInfo so that it can export ConstantRangesJohn Regehr2016-05-021-0/+16
| | | | | | | | | that it computes. Currently this is used for testing and precision tuning, but it might be used by optimizations later. Differential Revision: http://reviews.llvm.org/D19179 llvm-svn: 268291
* [CFLAA] Fix a use-of-invalid-pointer bug.George Burgess IV2016-05-021-1/+6
| | | | | | | | | | | | As shown in the diff, we used to add to CFLAA's cache by doing `Cache[Fn] = buildSetsFrom(Fn)`. `buildSetsFrom(Fn)` may cause `Cache` to reallocate its underlying storage, if this happens and `Cache[Fn]` was evaluated prior to `buildSetsFrom(Fn)`, then we'll store the result to a bad address. Patch by Jia Chen. llvm-svn: 268269
* Fixed MSVC 'not all control paths return a value' warningSimon Pilgrim2016-05-011-0/+1
| | | | llvm-svn: 268198
* [SCEV] When printing via -analysis, dump loop dispositionSanjoy Das2016-05-011-0/+25
| | | | | | | | | | | There are currently some bugs in tree around SCEV caching an incorrect loop disposition. Printing out loop dispositions will let us write whitebox tests as those are fixed. The dispositions are printed as a list in "inside out" order, i.e. innermost loop first. llvm-svn: 268177
* [ValueTracking] Make the code in lookThroughCastDavid Majnemer2016-04-291-16/+9
| | | | | | No functionality change is intended. llvm-svn: 268108
* [InstCombine] Determine the result of a select based on a dominating condition.Chad Rosier2016-04-291-1/+4
| | | | | | Differential Revision: http://reviews.llvm.org/D19550 llvm-svn: 268104
* [ValueTracking] matchSelectPattern needs to be more careful around FPDavid Majnemer2016-04-291-19/+31
| | | | | | | | | | | | matchSelectPattern attempts to see through casts which mask min/max patterns from being more obvious. Under certain circumstances, it would misidentify a sequence of instructions as a min/max because it assumed that folding casts would preserve the result. This is not the case for floating point <-> integer casts. This fixes PR27575. llvm-svn: 268086
* [BasicAA] Treat llvm.assume as not accessing memory in ↵Geoff Berry2016-04-291-0/+6
| | | | | | | | | | | | getModRefBehavior(Function) Reviewers: dberlin, chandlerc, hfinkel, reames, sanjoy Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D19730 llvm-svn: 268068
* Unify XDEBUG and EXPENSIVE_CHECKS (into the latter), and add an option to ↵Filipe Cabecinhas2016-04-292-2/+2
| | | | | | | | | | | | | | | | | | | the cmake build to enable them. Summary: Historically, we had a switch in the Makefiles for turning on "expensive checks". This has never been ported to the cmake build, but the (dead-ish) code is still around. This will also make it easier to turn it on in buildbots. Reviewers: chandlerc Subscribers: jyknight, mzolotukhin, RKSimon, gberry, llvm-commits Differential Revision: http://reviews.llvm.org/D19723 llvm-svn: 268050
* DivergenceAnalysis: Fix crash with unreachable blocksMatt Arsenault2016-04-291-0/+5
| | | | | | | Unreachable blocks may not be in the dominator tree, so don't crash on them. llvm-svn: 268001
* [Inliner] Formatting. NFC.Chad Rosier2016-04-281-36/+41
| | | | | | | Patch by Aditya Kumar! Differential Revision: http://reviews.llvm.org/D19047 llvm-svn: 267888
* [TLI] Unify LibFunc signature checking. NFCI.Ahmed Bougacha2016-04-274-96/+560
| | | | | | | | | I tried to be as close as possible to the strongest check that existed before; cleaning these up properly is left for future work. Differential Revision: http://reviews.llvm.org/D19469 llvm-svn: 267758
* [TLI] Fix indentation. NFC.Ahmed Bougacha2016-04-271-1/+1
| | | | llvm-svn: 267757
* [TTI] Add hook for vector extract with extensionMatthew Simpson2016-04-271-0/+8
| | | | | | | | | | | | | | | This change adds a new hook for estimating the cost of vector extracts followed by zero- and sign-extensions. The motivating example for this change is the SMOV and UMOV instructions on AArch64. These instructions move data from vector to general purpose registers while performing the corresponding extension (sign-extend for SMOV and zero-extend for UMOV) at the same time. For these operations, TargetTransformInfo can assume the extensions are free and only report the cost of the vector extract. The SLP vectorizer has been updated to make use of the new hook. Differential Revision: http://reviews.llvm.org/D18523 llvm-svn: 267725
* [ThinLTO] Refine fix to avoid renaming of uses in inline assembly.Teresa Johnson2016-04-271-6/+14
| | | | | | | | | | | | | | | | | Summary: Refine the workaround from r266877 that attempts to prevent renaming of locals in inline assembly, so that in addition to looking for a llvm.used local value, that there is at least one inline assembly call in the module. Otherwise, debug functions added to the llvm.used can block importing/exporting unnecessarily. Reviewers: joker.eph Subscribers: llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D19573 llvm-svn: 267717
* NFC. Introduce Value::getPointerDerferecnceableBytesArtur Pilipenko2016-04-271-27/+2
| | | | | | | | | | Extract a part of isDereferenceableAndAlignedPointer functionality to Value::getPointerDerferecnceableBytes. Currently it's a NFC, but in future I'm going to accumulate all the logic about value dereferenceability in this function similarly to Value::getPointerAlignment function (D16144). Reviewed By: reames Differential Revision: http://reviews.llvm.org/D17572 llvm-svn: 267708
* isSafeToLoadUnconditionally support queries without a contextArtur Pilipenko2016-04-271-3/+6
| | | | | | | | | | This is required to use this function from isSafeToSpeculativelyExecute Reviewed By: hfinkel Differential Revision: http://reviews.llvm.org/D16231 llvm-svn: 267692
* [LVI] Delete stale and misleading comment.Philip Reames2016-04-271-5/+0
| | | | llvm-svn: 267661
* [LVI] Add a comment explaining a subtle piece of codePhilip Reames2016-04-271-15/+23
| | | | | | Or at least, I didn't understand the implications the first several times I read it it. llvm-svn: 267648
* [LVI] Reduce compile time by lazily scanning blocks if neededPhilip Reames2016-04-271-26/+26
| | | | | | | | | | When encountering a non-local pointer, LVI would eagerly scan the block for dereferences of the given object to prove the pointer to be non null. That's all well and good, but *then* we'd go recurse through our input blocks. As a result, we could end up scanning each and every block we traverse, even if the final definition was obviously non null or we found a constant value somewhere up the chain. The previous code papered over this by using the isKnownNonNull routine from value tracking. This made the duplication less painful in the common case. Instead, we know do the block scan only *after* we've gotten the recursive results back. This lets us stop scanning individual blocks as soon as we've determined it to be non-null in any predecessor block and use our usual merge rules to propagate that information cheaply through successor blocks. For a pointer which can be found non-null, this does strictly less work and sometimes substaintially so. Note that the case where we *can't* prove something non-null is still the really expensive case. We end up scanning each and every block looking for a dereference and never end up finding one. llvm-svn: 267642
* [LVI] Cut short search if we know we can't return a useful resultPhilip Reames2016-04-261-9/+44
| | | | | | Previously we were recursing on our operands for unary and binary operators regardless of whether we knew how to reason about the operator in question. This has the effect of doing a potentially large amount of work, only to throw it away. By checking whether the operation is one LVI can handle, we can cut short the search and return the (overdefined) answer more quickly. The quality of the results produced should not change. llvm-svn: 267626
* [LVI] Apply transfer rule for overdefine inputs for binary operatorsPhilip Reames2016-04-261-11/+16
| | | | | | | | As pointed out by John Regehr over in http://reviews.llvm.org/D19485, LVI was being incredibly stupid about applying its transfer rules. Rather than gathering local facts from the expression itself, it was simply giving up entirely if one of the inputs was overdefined. This greatly impacts the precision of the overall analysis and makes it far more fragile as well. This patch builds on 267609 which did the same thing for unary casts. llvm-svn: 267620
* [LVI] A better fix for the assertion error introduced by 267609Philip Reames2016-04-261-10/+11
| | | | | | Essentially, I was using the wrong size function. For types which were sized, but not primitive, I wasn't getting a useful size for the operand and failed an assert. I fixed this, and also added a guard that the input is a sized type. Test case is for the original mistake. I'm not sure how to actually exercise the sized type check. llvm-svn: 267618
* [LVI] Speculative fix for assertion seen in clang botsPhilip Reames2016-04-261-0/+6
| | | | | | I'll clean this up and add a test case shortly. I want to make sure this does actually fix the bots; if not, I'll revert. llvm-svn: 267617
* [LVI] Infer local facts from unary expressionsPhilip Reames2016-04-261-16/+20
| | | | | | | | | | As pointed out by John Regehr over in http://reviews.llvm.org/D19485, LVI was being incredibly stupid about applying its transfer rules. Rather than gathering local facts from the expression itself, it was simply giving up entirely if one of the inputs was overdefined. This greatly impacts the precision of the overall analysis and makes it far more fragile as well. This patch implements only the unary operation case. Once this is in, I'll implement the same for the binary operations. Differential Revision: http://reviews.llvm.org/D19492 llvm-svn: 267609
* [LVI] Make a precondition explicit rather than handling a case which never ↵Philip Reames2016-04-251-1/+2
| | | | | | happens [NFC] llvm-svn: 267481
OpenPOWER on IntegriCloud