summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis
Commit message (Collapse)AuthorAgeFilesLines
* Fix comment from r232794. NFCNick Lewycky2015-03-201-1/+1
| | | | llvm-svn: 232796
* When simplifying a SCEV truncate by distributing, consider it a ↵Nick Lewycky2015-03-201-4/+6
| | | | | | simplification to replace a cast, even if we end up with a trunc around the term. Fixes PR22960! llvm-svn: 232794
* [SCEV] Make isImpliedCond smarter.Sanjoy Das2015-03-181-0/+44
| | | | | | | | | | | | | | | | | | Summary: This change teaches isImpliedCond to infer things like "X sgt 0" => "X - 1 sgt -1". The `ConstantRange` class has the logic to do the heavy lifting, this change simply gets ScalarEvolution to exploit that when reasonable. Depends on D8345 Reviewers: atrick Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8346 llvm-svn: 232576
* [ConstantRange] Split makeICmpRegion in two.Sanjoy Das2015-03-181-2/+2
| | | | | | | | | | | | | | | | | | | | Summary: This change splits `makeICmpRegion` into `makeAllowedICmpRegion` and `makeSatisfyingICmpRegion` with slightly different contracts. The first one is useful for determining what values some expression //may// take, given that a certain `icmp` evaluates to true. The second one is useful for determining what values are guaranteed to //satisfy// a given `icmp`. Reviewers: nlewycky Reviewed By: nlewycky Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8345 llvm-svn: 232575
* TLI: Add addVectorizableFunctionsFromVecLib.Michael Zolotukhin2015-03-171-0/+34
| | | | | | | | Also, add several entries to vectorizable functions table, and corresponding tests. The table isn't complete, it'll be populated later. Review: http://reviews.llvm.org/D8131 llvm-svn: 232531
* LoopVectorize: teach loop vectorizer to vectorize calls.Michael Zolotukhin2015-03-171-0/+7
| | | | | | | The tests would be committed in a commit for http://reviews.llvm.org/D8131 Review: http://reviews.llvm.org/D8095 llvm-svn: 232530
* TTI: Add getCallInstrCost.Michael Zolotukhin2015-03-171-0/+5
| | | | | Review: http://reviews.llvm.org/D8094 llvm-svn: 232524
* TLI: Add interface for querying whether a function is vectorizable.Michael Zolotukhin2015-03-171-0/+70
| | | | | Review: http://reviews.llvm.org/D8093 llvm-svn: 232523
* Fix doxygen comments from r232268Duncan P. N. Exon Smith2015-03-161-8/+8
| | | | llvm-svn: 232388
* Made CFLAA agree with clang-format. NFC.George Burgess IV2015-03-151-9/+7
| | | | | | So everyone's lives are easier in the future llvm-svn: 232293
* [opaque pointer type] more gep API migrationDavid Blaikie2015-03-141-4/+3
| | | | llvm-svn: 232274
* Recover the ability to 'b CheckFailed' after r231577Duncan P. N. Exon Smith2015-03-141-7/+14
| | | | | | | | | | Given that the stated purpose of `CheckFailed()` is to provide a nice spot for a breakpoint, it'd be nice not to have to use a regex to break on it. Recover the ability to simply use `b CheckFailed` by specializing the message-only version, and by changing the variadic version to call into the message-only version. llvm-svn: 232268
* [SCEV] Fix PR22856.Sanjoy Das2015-03-131-3/+6
| | | | | | | | | | | | | | | | | | | | Summary: ScalarEvolutionExpander assumes that the header block of a loop is a legal place to have a use for a phi node. This is true only for phis that are either in the header or dominate the header block, but it is not true for phi nodes that are strictly internal to the loop body. This change teaches ScalarEvolutionExpander to place uses of PHI nodes in the basic block the PHI nodes belong to. This is always legal, and `hoistIVInc` ensures that the said position dominates `IsomorphicInc`. Reviewers: atrick Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8311 llvm-svn: 232189
* Teach TBAA analysis to report errors on cyclic TBAA metadata rather than ↵Owen Anderson2015-03-131-4/+9
| | | | | | hanging. llvm-svn: 232144
* When forming an addrec out of a phi don't just look at the last computation ↵Nick Lewycky2015-03-131-5/+7
| | | | | | | | and steal its flags for our own, there may be other computations in the middle. Check whether the LHS of the computation is the phi itself and then we know it's safe to steal the flags. Fixes PR22795. There's a missed optimization opportunity where we could look at the full chain of computation and take the intersection of the flags instead of only looking one instruction deep. llvm-svn: 232134
* Stop calling DwarfEHPrepare from WinEHPrepareReid Kleckner2015-03-121-12/+0
| | | | | | | | Instead, run both EH preparation passes, and have them both ignore functions with unrecognized EH personalities. Pass delegation involved some hacky code for creating an AnalysisResolver that we don't need now. llvm-svn: 231995
* Infer known bits from dominating conditionsPhilip Reames2015-03-101-0/+212
| | | | | | | | | | | | | | | | | This patch adds limited support in ValueTracking for inferring known bits of a value from conditional expressions which must be true to reach the instruction we're trying to optimize. At this time, the feature is off by default. Once landed, I'm hoping for feedback from others on both profitability and compile time impact. Forms of conditional value propagation have been tried in LLVM before and have failed due to compile time problems. In an attempt to side step that, this patch only considers conditions where the edge leaving the branch dominates the context instruction. It does not attempt full dataflow. Even with that restriction, it handles many interesting cases: * Early exits from functions * Early exits from loops (for context instructions in the loop and after the check) * Conditions which control entry into loops, including multi-version loops (such as those produced during vectorization, IRCE, loop unswitch, etc..) Possible applications include optimizing using information provided by constructs such as: preconditions, assumptions, null checks, & range checks. This patch implements two approaches to the problem that need further benchmarking. Approach 1 is to directly walk the dominator tree looking for interesting conditions. Approach 2 is to inspect other uses of the value being queried for interesting comparisons. From initial benchmarking, it appears that Approach 2 is faster than Approach 1, but this needs to be further validated. Differential Revision: http://reviews.llvm.org/D7708 llvm-svn: 231879
* [LoopAccesses] Add debug message to indicate the result of the analysisAdam Nemet2015-03-101-4/+7
| | | | | | | | | | The debug message was pretty confusing here. It only reported the situation with memchecks without the result of the dependence analysis. Now it prints whether the loop is safe from the POV of the dependence analysis and if yes, whether we need memchecks. llvm-svn: 231854
* LoopAccessAnalysis: Silence -Wreturn-type diagnostic from GCCDavid Majnemer2015-03-101-0/+3
| | | | llvm-svn: 231836
* [LAA-memchecks] Comment improvementAdam Nemet2015-03-101-2/+2
| | | | | | I forgot to roll this into r231816. It was requested by Hal in D8122. llvm-svn: 231821
* [LAA-memchecks 3/3] Introduce pointer partitions for memchecksAdam Nemet2015-03-101-10/+36
| | | | | | | | | | | | | | | | | This is the final patch that actually introduces the new parameter of partition mapping to RuntimePointerCheck::needsChecking. Another API (LAI::getInstructionsForAccess) is also exposed that helps to map pointers to instructions because ultimately we partition instructions. The WIP version of the Loop Distribution pass in D6930 has been adapted to use all this. See for example, how InstrPartitionContainer::computePartitionSetForPointers sets up the partitions using the above API and then calls to LAI::addRuntimeCheck with the pointer partitions. llvm-svn: 231818
* [LAA-memchecks 2/3] Move number of memcheck threshold checking to LVAdam Nemet2015-03-101-27/+3
| | | | | | | | | | | | | | | | | | | | | Now the analysis won't "fail" if the memchecks exceed the threshold. It is the transform pass' responsibility to perform the check. This allows the transform pass to further analyze/eliminate the memchecks. E.g. in Loop distribution we only need to check pointers that end up in different partitions. Note that there is a slight change of functionality here. The logic in analyzeLoop is that if dependence checking fails due to non-constant distance between the pointers, another attempt is made to prove safety of the dependences purely using run-time checks. Before this patch we could fail the loop due to exceeding the memcheck threshold after the first step, now we only check the threshold in the client after the full analysis. There is no measurable compile-time effect but I wanted to record this here. llvm-svn: 231817
* [LAA-memchecks 1/3] Split out NumComparisons checks. NFCAdam Nemet2015-03-101-22/+30
| | | | | | | | | | | | | | | The check for the number of memchecks will be moved to the client of this analysis. Besides allowing for transform-specific thresholds, this also lets Loop Distribution post-process the memchecks; Loop Distribution only needs memchecks between pointers of different partitions. The motivation for this first patch is to untangle the CanDoRT check from the NumComparison check before moving the NumComparison part. CanDoRT means that we couldn't determine the bounds for the pointer. Note that NumComparison is set independent of this flag. llvm-svn: 231816
* [LoopAccesses 3/3] Print the dependences with -analyzeAdam Nemet2015-03-101-1/+20
| | | | | | | | | | The dependences are now expose through the new getInterestingDependences API so we can use that with -analyze too and fix the FIXME. This lets us remove the test that relied on -debug to check the dependences. llvm-svn: 231807
* [LoopAccesses 2/3] Allow querying of interesting dependencesAdam Nemet2015-03-101-20/+100
| | | | | | | | | | | | | | | | | | | | | | | Gather an array of interesting dependences rather than just failing after the first unsafe one and regarding the loop unsafe. Loop Distribution needs to be able to collect all dependences in order to isolate the dependence cycles into their own partition. Since the dependence checking algorithm is quadratic in terms of accesses sharing the same underlying pointer, I am applying a cut-off threshold (MaxInterestingDependence). Exceeding that, the logic reverts back to the original approach deeming the loop unsafe upon encountering the first unsafe dependence. The main idea of the patch is to split isDepedent from directly answering the question whether the dep is safe for vectorization to return a dependence type which then gets mapped to old boolean result using Dependence::isSafeForVectorization. Tested that this was compile-time neutral on SpecINT2006 LTO bitcode inputs. No assembly change on the testsuite including external. llvm-svn: 231806
* [LoopAccesses 1/3] Expose MemoryDepChecker to LAA usersAdam Nemet2015-03-101-127/+8
| | | | | | | | | | | | LoopDistribution needs to query various results of the dependence analysis. This series will expose some more APIs and state of the dependence checker. This patch is a simple one to just expose the DepChecker instance. The set is compile-time neutral measured with LTO bitcode files of SpecINT2006. Also there is no assembly change on the testsuite. llvm-svn: 231805
* Fix a memory corruption in Dependency Analysis.Karthik Bhat2015-03-101-0/+2
| | | | | | | | | | This crash occurs due to memory corruption when trying to update dependency direction based on Constraints. This crash was observed during lnt regression of Polybench benchmark test case dynprog. Review: http://reviews.llvm.org/D8059 llvm-svn: 231788
* Fix a crash in Dependency Analysis.Karthik Bhat2015-03-101-6/+6
| | | | | | | | | | | | | | | | | | | | This crash in Dependency analysis is because we assume here that in case of UsefulGEP both source and destination have the same number of operands which may not be true. This incorrect assumption results in crash while populating Pairs. Fix the same. This crash was observed during lnt regression for code such as- struct s{ int A[10][10]; int C[10][10][10]; } S; void dep_constraint_crash_test(int k,int N) { for( int i=0;i<N;i++) for( int j=0;j<N;j++) S.A[0][0] = S.C[0][0][k]; } Review: http://reviews.llvm.org/D8162 llvm-svn: 231784
* removed function names from comments; NFCSanjay Patel2015-03-101-10/+10
| | | | llvm-svn: 231749
* use range-based for loops; NFCSanjay Patel2015-03-101-12/+9
| | | | llvm-svn: 231747
* Added ConstantExpr support to CFLAA.George Burgess IV2015-03-101-40/+143
| | | | | | | | CFLAA didn't know how to properly handle ConstantExprs; it would silently ignore them. This was a problem if the ConstantExpr is, say, a GEP of a global, because CFLAA wouldn't realize that there's a global there. :) llvm-svn: 231743
* Added special handling for inttoptr in CFLAA.George Burgess IV2015-03-101-10/+22
| | | | | | | | | | We now treat pointers given to ptrtoint and pointers retrieved from inttoptr as similar to arguments or globals (can alias anything, etc.) This solves some of the problems we were having with giving incorrect results. llvm-svn: 231741
* DataLayout is mandatory, update the API to reflect it with references.Mehdi Amini2015-03-1018-859/+710
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Now that the DataLayout is a mandatory part of the module, let's start cleaning the codebase. This patch is a first attempt at doing that. This patch is not exactly NFC as for instance some places were passing a nullptr instead of the DataLayout, possibly just because there was a default value on the DataLayout argument to many functions in the API. Even though it is not purely NFC, there is no change in the validation. I turned as many pointer to DataLayout to references, this helped figuring out all the places where a nullptr could come up. I had initially a local version of this patch broken into over 30 independant, commits but some later commit were cleaning the API and touching part of the code modified in the previous commits, so it seemed cleaner without the intermediate state. Test Plan: Reviewers: echristo Subscribers: llvm-commits From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231740
* [SCEV] Unify getUnsignedRange and getSignedRangeSanjoy Das2015-03-091-209/+126
| | | | | | | | | | | | | | | | | | | | | | Summary: This removes some duplicated code, and also helps optimization: e.g. in the test case added, `%idx ULT 128` in `@x` is not currently optimized to `true` by `-indvars` but will be, after this change. The only functional change in ths commit is that for add recurrences, ScalarEvolution::getRange will be more aggressive -- computing the unsigned (resp. signed) range for a SCEVAddRecExpr will now look at the NSW (resp. NUW) bits and check for signed (resp. unsigned) overflow. This can be a strict improvement in some cases (such as the attached test case), and should be no worse in other cases. Reviewers: atrick, nlewycky Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8142 llvm-svn: 231709
* [SCEV] Add a `scalar-evolution-print-constant-ranges' optionSanjoy Das2015-03-091-0/+12
| | | | | | | | | | | | | | Summary: Unused in this commit, but will be used in a subsequent change (D8142) by a FileCheck test. Reviewers: atrick Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8143 llvm-svn: 231708
* Drop the hacks used for partial C99 math libraries.Benjamin Kramer2015-03-091-10/+0
| | | | | | All supported platforms have half-way decent C99 support. llvm-svn: 231679
* InstCombine: fix fold "fcmp x, undef" to account for NaNMehdi Amini2015-03-091-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | Summary: See the two test cases. ; Can fold fcmp with undef on one side by choosing NaN for the undef ; Can fold fcmp with undef on both side ; fcmp u_pred undef, undef -> true ; fcmp o_pred undef, undef -> false ; because whatever you choose for the first undef ; you can choose NaN for the other undef Reviewers: hfinkel, chandlerc, majnemer Reviewed By: majnemer Subscribers: majnemer, llvm-commits Differential Revision: http://reviews.llvm.org/D7617 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231626
* DCE: isArrayMalloc() is not used neither in LLVM nor ClangMehdi Amini2015-03-091-17/+0
| | | | | From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231624
* Simplify expressions involving boolean constants with clang-tidyDavid Blaikie2015-03-091-2/+2
| | | | | | | | Patch by Richard (legalize at xmission dot com). Differential Revision: http://reviews.llvm.org/D8154 llvm-svn: 231617
* Make static variables const if possible. Makes them go into a read-only section.Benjamin Kramer2015-03-082-11/+10
| | | | | | Or fold them into a initializer list which has the same effect. NFC. llvm-svn: 231598
* Make the assertion macros in Verifier and Linter truly variadic.Benjamin Kramer2015-03-071-132/+121
| | | | | | NFC. llvm-svn: 231577
* Do not restrict interleaved unrolling to small loops, depending on the target.Olivier Sallenave2015-03-061-0/+4
| | | | llvm-svn: 231528
* Avoid calls to dumpPassInfo and RegionBase<Tr>::getNameStr() in RGPassManager ifChad Rosier2015-03-061-10/+14
| | | | | | | | | | | | | | | | | | -debug-pass is not specified, as the string is only used when dumping pass information. There is a big cost of determining the name in ReginBase<Tr>:getNameStr() if the region's entry or exit block doesn't have a name. This is the case for the Release build, as names are not preserved by the front-end. RegionPass is mainly used by Polly, resulting in long compile time for one file of a customer application with the Release build (1m24s) vs Release+Asserts build (10s) when Polly is used. With this change, the compile time with the Release build went down to 8s. Patch by Sanjin Sijaric <ssijaric@codeaurora.org>! Phabricator: http://reviews.llvm.org/D8076 llvm-svn: 231485
* Teach ComputeNumSignBits about signed reminder.Nadav Rotem2015-03-061-1/+27
| | | | | | This optimization a continuation of r231140 that reasoned about signed div. llvm-svn: 231433
* Reformat.NAKAMURA Takumi2015-03-051-14/+11
| | | | llvm-svn: 231336
* Revert r231103, "FullDependenceAnalysis: Avoid using the (deprecated in ↵NAKAMURA Takumi2015-03-051-22/+23
| | | | | | | | C++11) copy ctor" It is miscompiled on msc18. llvm-svn: 231335
* Revert r231104, "unique_ptrify FullDependenceAnalysis::DV", to appease msc18 ↵NAKAMURA Takumi2015-03-051-5/+9
| | | | | | C2280. llvm-svn: 231334
* ScalarEvolution.cpp: Appease g++-4.7. He missed implicit "this" in lambda.NAKAMURA Takumi2015-03-051-1/+1
| | | | llvm-svn: 231331
* [SCEV] make SCEV smarter about proving no-wrap.Sanjoy Das2015-03-041-0/+93
| | | | | | | | | | | | | | | Summary: Teach SCEV to prove no overflow for an add recurrence by proving something about the range of another add recurrence a loop-invariant distance away from it. Reviewers: atrick, hfinkel Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D7980 llvm-svn: 231305
* Make DataLayout Non-Optional in the ModuleMehdi Amini2015-03-0421-45/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: DataLayout keeps the string used for its creation. As a side effect it is no longer needed in the Module. This is "almost" NFC, the string is no longer canonicalized, you can't rely on two "equals" DataLayout having the same string returned by getStringRepresentation(). Get rid of DataLayoutPass: the DataLayout is in the Module The DataLayout is "per-module", let's enforce this by not duplicating it more than necessary. One more step toward non-optionality of the DataLayout in the module. Make DataLayout Non-Optional in the Module Module->getDataLayout() will never returns nullptr anymore. Reviewers: echristo Subscribers: resistor, llvm-commits, jholewinski Differential Revision: http://reviews.llvm.org/D7992 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231270
OpenPOWER on IntegriCloud