summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer/Core/LoopUnrolling.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [analyzer] NFC: Move getStmt() and createEndOfPath() out of PathDiagnostic.Artem Dergachev2019-09-111-1/+3
| | | | | | | | | | These static functions deal with ExplodedNodes which is something we don't want the PathDiagnostic interface to know anything about, as it's planned to be moved out of libStaticAnalyzerCore. Differential Revision: https://reviews.llvm.org/D67382 llvm-svn: 371659
* [CFG] NFC: Remove implicit conversion from CFGTerminator to Stmt *.Artem Dergachev2019-05-241-1/+1
| | | | | | | | | | | Turn it into a variant class instead. This conversion does indeed save some code but there's a plan to add support for more kinds of terminators that aren't necessarily based on statements, and with those in mind it becomes more and more confusing to have CFGTerminators implicitly convertible to a Stmt *. Differential Revision: https://reviews.llvm.org/D61814 llvm-svn: 361586
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [analyzer] Unroll the loop when it has a unsigned counter.Henry Wong2018-03-311-7/+9
| | | | | | | | | | | | | | | | | Summary: The original implementation in the `LoopUnrolling.cpp` didn't consider the case where the counter is unsigned. This case is only handled in `simpleCondition()`, but this is not enough, we also need to deal with the unsinged counter with the counter initialization. Since `IntegerLiteral` is `signed`, there is a `ImplicitCastExpr<IntegralCast>` in `unsigned counter = IntergerLiteral`. This patch add the `ignoringParenImpCasts()` in the `IntegerLiteral` matcher. Reviewers: szepet, a.sidorin, NoQ, george.karpenkov Reviewed By: szepet, george.karpenkov Subscribers: xazax.hun, rnkovacs, cfe-commits, MTC Differential Revision: https://reviews.llvm.org/D45086 llvm-svn: 328919
* [analyzer] LoopUnrolling: update the matched assignment operatorsPeter Szecsi2018-03-271-3/+1
| | | | | | | | | Extended the matched assignment operators when checking for bound changes in a body of the loop by using the freshly added isAssignmentOperator matcher. This covers all the (current) possible assignments, tests added as well. Differential Revision: https://reviews.llvm.org/D38921 llvm-svn: 328619
* [analyzer] LoopUnrolling: check the bitwidth of the used numbers (pr34943)Peter Szecsi2017-10-281-2/+9
| | | | | | | | | | | | | | | The loop unrolling feature aims to track the maximum possible steps a loop can make. In order to implement this, it investigates the initial value of the counter variable and the bound number. (It has to be known.) These numbers are used as llvm::APInts, however, it was not checked if their bitwidths are the same which lead to some crashes. This revision solves this problem by extending the "shorter" one (to the length of the "longer" one). For the detailed bug report, see: https://bugs.llvm.org/show_bug.cgi?id=34943 Differential Revision: https://reviews.llvm.org/D38922 llvm-svn: 316830
* [StaticAnalyzer] LoopUnrolling: Keep track the maximum number of steps for ↵Peter Szecsi2017-08-281-30/+55
| | | | | | | | | | | | each loop This way the unrolling can be restricted for loops which will take at most a given number of steps. It is defined as 128 in this patch and it seems to have a good number for that purpose. Differential Revision: https://reviews.llvm.org/D37181 llvm-svn: 311883
* [StaticAnalyzer] LoopUnrolling: Excluding loops which splits the statePeter Szecsi2017-08-281-1/+26
| | | | | | | | | | Added check if the execution of the last step of the given unrolled loop has generated more branches. If yes, than treat it as a normal (non-unrolled) loop in the remaining part of the analysis. Differential Revision: https://reviews.llvm.org/D36962 llvm-svn: 311881
* [StaticAnalyzer] LoopUnrolling fixesPeter Szecsi2017-08-281-9/+2
| | | | | | | | | | | | | | 1. The LoopUnrolling feature needs the LoopExit included in the CFG so added this dependency via the config options 2. The LoopExit element can be encountered even if we haven't encountered the block of the corresponding LoopStmt. So the asserts were not right. 3. If we are caching out the Node then we get a nullptr from generateNode which case was not handled. Differential Revision: https://reviews.llvm.org/D37103 llvm-svn: 311880
* [StaticAnalyzer] LoopUnrolling: Track a LoopStack in order to completely ↵Peter Szecsi2017-08-211-79/+67
| | | | | | | | | | | | | unroll specific loops The LoopExit CFG information provides the opportunity to not mark the loops but having a stack which tracks if a loop is unrolled or not. So in case of simulating a loop we just add it and the information if it meets the requirements to be unrolled to the top of the stack. Differential Revision: https://reviews.llvm.org/D35684 llvm-svn: 311346
* [StaticAnalyzer] LoopUnrolling: Exclude cases where the counter is escaped ↵Peter Szecsi2017-08-191-36/+83
| | | | | | | | | | | before the loop Adding escape check for the counter variable of the loop. It is achieved by jumping back on the ExplodedGraph to its declStmt. Differential Revision: https://reviews.llvm.org/D35657 llvm-svn: 311234
* [StaticAnalyzer] LoopUnrolling - Attempt #2 to fix a crash in r309006.Peter Szecsi2017-07-251-2/+2
| | | | llvm-svn: 309061
* [StaticAnalyzer] LoopUnrolling - Attempt to fix a crash in r309006.Peter Szecsi2017-07-251-1/+3
| | | | llvm-svn: 309036
* [StaticAnalyzer] Completely unrolling specific loops with known bound optionPeter Szecsi2017-07-251-0/+207
| | | | | | | | | | | | | | | | | This feature allows the analyzer to consider loops to completely unroll. New requirements/rules (for unrolling) can be added easily via ASTMatchers. Right now it is hidden behind a flag, the aim is to find the correct heuristic and create a solution which results higher coverage % and more precise analysis, thus can be enabled by default. Right now the blocks which belong to an unrolled loop are marked by the LoopVisitor which adds them to the ProgramState. Then whenever we encounter a CFGBlock in the processCFGBlockEntrance which is marked then we skip its investigating. That means, it won't be considered to be visited more than the maximal bound for visiting since it won't be checked. llvm-svn: 309006
* Revert "[StaticAnalyzer] Completely unrolling specific loops with known ↵Peter Szecsi2017-07-201-203/+0
| | | | | | | | | | bound option" Revert r308561 and r308558. Clang-ppc64be-linux seems to crash while running the test cases. llvm-svn: 308592
* [StaticAnalyzer] Completely unrolling specific loops with known bound option Peter Szecsi2017-07-201-0/+203
Missing files added to rL308558. llvm-svn: 308561
OpenPOWER on IntegriCloud