summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis/DemandedBits.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [DemandedBits] Reduce number of duplicated DenseMap lookups.Benjamin Kramer2016-07-211-5/+4
| | | | | | No functionality change intended. llvm-svn: 276278
* Port DemandedBits to the new pass manager.Michael Kuperstein2016-04-181-22/+42
| | | | | | Differential Revision: http://reviews.llvm.org/D18679 llvm-svn: 266699
* [NFC] Header cleanupMehdi Amini2016-04-181-1/+0
| | | | | | | | | | | | | | Removed some unused headers, replaced some headers with forward class declarations. Found using simple scripts like this one: clear && ack --cpp -l '#include "llvm/ADT/IndexedMap.h"' | xargs grep -L 'IndexedMap[<]' | xargs grep -n --color=auto 'IndexedMap' Patch by Eugene Kosov <claprix@yandex.ru> Differential Revision: http://reviews.llvm.org/D19219 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266595
* [DemandedBits] Revert r249687 due to PR26071James Molloy2016-02-031-7/+0
| | | | | | | | | | | | | | This regresses a test in LoopVectorize, so I'll need to go away and think about how to solve this in a way that isn't broken. From the writeup in PR26071: What's happening is that ComputeKnownZeroes is telling us that all bits except the LSB are zero. We're then deciding that only the LSB needs to be demanded from the icmp's inputs. This is where we're wrong - we're assuming that after simplification the bits that were known zero will continue to be known zero. But they're not - during trivialization the upper bits get changed (because an XOR isn't shrunk), so the icmp fails. The fault is in demandedbits - its contract does clearly state that a non-demanded bit may either be zero or one. llvm-svn: 259649
* Make some headers self-contained, remove unused includes that violate layering.Benjamin Kramer2016-01-271-1/+0
| | | | llvm-svn: 258937
* [DemandedBits] Fix computation of demanded bits for ICmpsJames Molloy2016-01-251-1/+1
| | | | | | | | | | The computation of ICmp demanded bits is independent of the individual operand being evaluated. We simply return a mask consisting of the minimum leading zeroes of both operands. We were incorrectly passing "I" to ComputeKnownBits - this should be "UserI->getOperand(0)". In cases where we were evaluating the 1th operand, we were taking the minimum leading zeroes of it and itself. This should fix PR26266. llvm-svn: 258690
* Compute demanded bits for icmp instructionsJames Molloy2015-10-081-0/+7
| | | | | | | | | Instead of bailing out when we see an icmp, we can instead at least say that if the upper bits of both operands are known zero, they are not demanded. This doesn't help with signed comparisons, but it's at least better than bailing out. llvm-svn: 249687
* Treat Mul just like Add and SubtractJames Molloy2015-10-081-0/+12
| | | | | | | | | | Like adds and subtracts, muls ripple only to the left so we can use the same logic. While we're here, add a print method to DemandedBits so it can be used with -analyze, which we'll use in the testcase. llvm-svn: 249686
* Make demanded bits lazyJames Molloy2015-10-081-7/+19
| | | | | | | | | | The algorithm itself is still eager, but it doesn't get run until a query function is called. This greatly reduces the compile-time impact of requiring DemandedBits when at runtime it is not often used. NFCI. llvm-svn: 249685
* Untabify.NAKAMURA Takumi2015-09-221-7/+5
| | | | llvm-svn: 248264
* Reformat comment lines.NAKAMURA Takumi2015-09-221-2/+2
| | | | llvm-svn: 248262
* Reformat.NAKAMURA Takumi2015-09-221-2/+1
| | | | llvm-svn: 248261
* Separate out BDCE's analysis into a separate DemandedBits analysis.James Molloy2015-08-141-0/+364
This allows other areas of the compiler to use BDCE's bit-tracking. NFCI. llvm-svn: 245039
OpenPOWER on IntegriCloud