summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms/CorrelatedValuePropagation/range.ll
Commit message (Collapse)AuthorAgeFilesLines
* [CVP] Remove a masking operation if range information implies it's a noopPhilip Reames2019-10-111-2/+1
| | | | | | | | | | This is really a known bits style transformation, but known bits isn't context sensitive. The particular case which comes up happens to involve a range which allows range based reasoning to eliminate the mask pattern, so handle that case specifically in CVP. InstCombine likes to generate the mask-by-low-bits pattern when widening an arithmetic expression which includes a zext in the middle. Differential Revision: https://reviews.llvm.org/D68811 llvm-svn: 374506
* [CVP] Reenable nowrap flag inferenceNikita Popov2019-06-241-1/+1
| | | | | | | | | | | Inference of nowrap flags in CVP has been disabled, because it triggered a bug in LFTR (https://bugs.llvm.org/show_bug.cgi?id=31181). This issue has been fixed in D60935, so we should be able to reenable nowrap flag inference now. Differential Revision: https://reviews.llvm.org/D62776 llvm-svn: 364228
* Revert "Temporarily Revert "Add basic loop fusion pass.""Eric Christopher2019-04-171-0/+917
| | | | | | | | The reversion apparently deleted the test/Transforms directory. Will be re-reverting again. llvm-svn: 358552
* Temporarily Revert "Add basic loop fusion pass."Eric Christopher2019-04-171-917/+0
| | | | | | | | As it's causing some bot failures (and per request from kbarton). This reverts commit r358543/ab70da07286e618016e78247e4a24fcb84077fda. llvm-svn: 358546
* [CVP] auto-generate complete test checks; NFCSanjay Patel2018-11-291-120/+390
| | | | llvm-svn: 347866
* [CVP] Extend tests to illustrate an old patch isn't neededPhilip Reames2018-08-241-0/+42
| | | | | | Back in https://reviews.llvm.org/D19559, I tried to teach CVP about range facts implied by value/value icmps (i.e. no constants.) In the meantime, we've implemented the optimization, but I couldn't find tests checked in, so adding them. llvm-svn: 340660
* [LVI] Constant-propagate a zero extension of the switch condition value ↵Hiroshi Yamauchi2017-08-031-0/+141
| | | | | | | | | | | | | | | | | | | | | | | | | | | through case edges Summary: (This is a second attempt as https://reviews.llvm.org/D34822 was reverted.) LazyValueInfo currently computes the constant value of the switch condition through case edges, which allows the constant value to be propagated through the case edges. But we have seen a case where a zero-extended value of the switch condition is used past case edges for which the constant propagation doesn't occur. This patch adds a small logic to handle such a case in getEdgeValueLocal(). This is motivated by the Python 2.7 eval loop in PyEval_EvalFrameEx() where the lack of the constant propagation causes longer live ranges and more spill code than necessary. With this patch, we see that the code size of PyEval_EvalFrameEx() decreases by ~5.4% and a performance test improves by ~4.6%. Reviewers: sanjoy Reviewed By: sanjoy Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D36247 llvm-svn: 309986
* Revert r309415: "[LVI] Constant-propagate a zero extension of the switch ↵Daniel Jasper2017-08-011-114/+0
| | | | | | | | | condition value through case edges" This causes assertion failures in (a somewhat old version of) SpiderMonkey. I have already forwarded reproduction instructions to the patch author. llvm-svn: 309659
* [LVI] Constant-propagate a zero extension of the switch condition value ↵Hiroshi Yamauchi2017-07-281-0/+114
| | | | | | | | | | | | | | | | | | | | | | | | | | | | through case edges Summary: LazyValueInfo currently computes the constant value of the switch condition through case edges, which allows the constant value to be propagated through the case edges. But we have seen a case where a zero-extended value of the switch condition is used past case edges for which the constant propagation doesn't occur. This patch adds a small logic to handle such a case in getEdgeValueLocal(). This is motivated by the Python 2.7 eval loop in PyEval_EvalFrameEx() where the lack of the constant propagation causes longer live ranges and more spill code than necessary. With this patch, we see that the code size of PyEval_EvalFrameEx() decreases by ~5.4% and a performance test improves by ~4.6%. Reviewers: wmi, dberlin, sanjoy Reviewed By: sanjoy Subscribers: davide, davidxl, llvm-commits Differential Revision: https://reviews.llvm.org/D34822 llvm-svn: 309415
* [LVI] Take range metadata into account while calculating icmp condition ↵Artur Pilipenko2016-08-121-0/+17
| | | | | | | | | | | | | | | | | constraints Take range metadata into account for conditions like this: %length = load i32, i32* %length_ptr, !range !{i32 0, i32 2147483647} %cmp = icmp ult i32 %a, %length This is a common pattern for range checks where the length of the array is dynamically loaded. Reviewed By: sanjoy Differential Revision: https://reviews.llvm.org/D23267 llvm-svn: 278496
* [LVI] Handle any predicate in comparisons like icmp <pred> (add Val, ↵Artur Pilipenko2016-08-121-0/+130
| | | | | | | | | | | | | | | | | Offset), ... Currently LVI can only gather value constraints from comparisons like: * icmp <pred> Val, ... * icmp ult (add Val, Offset), ... In fact we can handle any predicate in latter comparisons. Reviewed By: sanjoy Differential Revision: https://reviews.llvm.org/D23357 llvm-svn: 278493
* [LVI] Make LVI smarter about comparisons with non-constantsArtur Pilipenko2016-08-091-0/+112
| | | | | | | | | | Make LVI smarter about comparisons with a non-constant. For example, a s< b constraints a to be in [INT_MIN, INT_MAX) range. This is a part of https://llvm.org/bugs/show_bug.cgi?id=28620 fix. Reviewed By: sanjoy Differential Revision: https://reviews.llvm.org/D23205 llvm-svn: 278122
* Revert 278107 which causes buildbot failures and in addition has wrong ↵Artur Pilipenko2016-08-091-112/+0
| | | | | | commit message llvm-svn: 278109
* Teach CorrelatedValuePropagation to mark adds as no wrapArtur Pilipenko2016-08-091-0/+112
| | | | | | | | | | Use LVI to prove that adds do not wrap. The change is motivated by https://llvm.org/bugs/show_bug.cgi?id=28620 bug and it's the first step to fix that problem. Reviewed By: sanjoy Differential Revision: http://reviews.llvm.org/D23059 llvm-svn: 278107
* [LVI] Fix a bug which prevented use of !range metadata within a queryPhilip Reames2016-03-041-0/+14
| | | | | | The diff is relatively large since I took a chance to rearrange the code I had to touch in a more obvious way, but the key bit is merely using the !range metadata when we can't analyze the instruction further. The previous !range metadata code was essentially just dead since no binary operator or cast will have !range metadata (per Verifier) and it was otherwise dropped on the floor. llvm-svn: 262751
* [LVI/CVP] Teach LVI about range metadataPhilip Reames2015-10-291-0/+24
| | | | | | | | | | | | | | Somewhat shockingly for an analysis pass which is computing constant ranges, LVI did not understand the ranges provided by range metadata. As part of this change, I included a change to CVP primarily because doing so made it much easier to write small self contained test cases. CVP was previously only handling the non-local operand case, but given that LVI can sometimes figure out information about instructions standalone, I don't see any reason to restrict this. There could possibly be a compile time impact from this, but I suspect it should be minimal. If anyone has an example which substaintially regresses, please let me know. I could restrict the block local handling to ICmps feeding Terminator instructions if needed. Note that this patch continues a somewhat bad practice in LVI. In many cases, we know facts about values, and separate context sensitive facts about values. LVI makes no effort to distinguish and will frequently cache the same value fact repeatedly for different contexts. I would like to change this, but that's a large enough change that I want it to go in separately with clear documentation of what's changing. Other examples of this include the non-null handling, and arguments. As a meta comment: the entire motivation of this change was being able to write smaller (aka reasonable sized) test cases for a future patch teaching LVI about select instructions. Differential Revision: http://reviews.llvm.org/D13543 llvm-svn: 251606
* Update Transforms tests to use CHECK-LABEL for easier debugging. No ↵Stephen Lin2013-07-141-7/+7
| | | | | | | | | | | | | | | | | | | | | | functionality change. This update was done with the following bash script: find test/Transforms -name "*.ll" | \ while read NAME; do echo "$NAME" if ! grep -q "^; *RUN: *llc" $NAME; then TEMP=`mktemp -t temp` cp $NAME $TEMP sed -n "s/^define [^@]*@\([A-Za-z0-9_]*\)(.*$/\1/p" < $NAME | \ while read FUNC; do sed -i '' "s/;\(.*\)\([A-Za-z0-9_]*\):\( *\)@$FUNC\([( ]*\)\$/;\1\2-LABEL:\3@$FUNC(/g" $TEMP done mv $TEMP $NAME fi done llvm-svn: 186268
* make LazyValueInfo analyze the default case of switch statements (we know ↵Nuno Lopes2012-06-281-0/+23
| | | | | | that in the default branch the value cannot be any of the switch cases) llvm-svn: 159353
* make LVI::getEdgeValue() always intersect the constraints of the edge with ↵Nuno Lopes2012-06-281-0/+44
| | | | | | the range of the block. Previously it was only performing the intersection for a few cases, thus losing precision llvm-svn: 159320
* allow LazyValueInfo::getEdgeValue() to reason about multiple edges from the ↵Nuno Lopes2012-05-181-0/+28
| | | | | | same switch instruction by doing union of ranges (which may still be conservative, but it's more aggressive than before) llvm-svn: 157071
* add test case for bugfix in r157032Nuno Lopes2012-05-181-0/+29
| | | | llvm-svn: 157058
* LVI: Recognize the form instcombine canonicalizes range checks into when ↵Benjamin Kramer2012-03-021-0/+43
forming constant ranges. This could probably be made a lot smarter, but this is a common case and doesn't require LVI to scan a lot of code. With this change CVP can optimize away the "shift == 0" case in Hashing.h that only gets hit when "shift" is in a range not containing 0. llvm-svn: 151919
OpenPOWER on IntegriCloud