summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis/ValueTracking.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Factor out the multiply analysis code in ComputeMaskedBits and apply it to theNick Lewycky2012-03-181-62/+76
| | | | | | | | overflow checking multiply intrinsic as well. Add a test for this, updating the test from grep to FileCheck. llvm-svn: 153028
* Factor out the analysis of addition and subtraction in ComputeMaskedBits. ReuseNick Lewycky2012-03-091-83/+123
| | | | | | it to analyze extractvalue(llvm.[us](add|sub).with.overflow.*) intrinsics! llvm-svn: 152398
* No functionality change. Type::isSized() can be expensive, so avoid calling itNick Lewycky2012-03-071-8/+10
| | | | | | until after other inexpensive tests. llvm-svn: 152195
* A few more cases of missing masking in ComputeMaskedBits; found by inspection.Eli Friedman2012-03-051-3/+3
| | | | llvm-svn: 152070
* Make sure we don't return bits outside the mask in ComputeMaskedBits. PR12189.Eli Friedman2012-03-051-2/+2
| | | | llvm-svn: 152066
* Remove some dead code and tidy things up now that vectors use ConstantDataVectorChris Lattner2012-02-061-13/+2
| | | | | | instead of always using ConstantVector. llvm-svn: 149912
* [unwind removal] Remove all of the code for the dead 'unwind' instruction. ThereBill Wendling2012-02-061-1/+0
| | | | | | | were no 'unwind' instructions being generated before this, so this is in effect a no-op. llvm-svn: 149906
* reapply the patches reverted in r149470 that reenable ConstantDataArray,Chris Lattner2012-02-051-136/+44
| | | | | | | | | but with a critical fix to the SelectionDAG code that optimizes copies from strings into immediate stores: the previous code was stopping reading string data at the first nul. Address this by adding a new argument to llvm::getConstantStringInfo, preserving the behavior before the patch. llvm-svn: 149800
* Revert Chris' commits up to r149348 that started causing VMCoreTests unit ↵Argyrios Kyrtzidis2012-02-011-42/+137
| | | | | | | | | | | | | | | | | | | test to fail. These are: r149348 r149351 r149352 r149354 r149356 r149357 r149361 r149362 r149364 r149365 llvm-svn: 149470
* remove the last vestiges of llvm::GetConstantStringInfo, in CodeGen.Chris Lattner2012-01-311-10/+0
| | | | llvm-svn: 149356
* Change ConstantArray::get to form a ConstantDataArray when possible,Chris Lattner2012-01-311-136/+51
| | | | | | | | | | | | | | | kicking in the big win of ConstantDataArray. As part of this, change the implementation of GetConstantStringInfo in ValueTracking to work with ConstantDataArray (and not ConstantArray) making it dramatically, amazingly, more efficient in the process and renaming it to getConstantStringInfo. This keeps around a GetConstantStringInfo entrypoint that (grossly) forwards to getConstantStringInfo and constructs the std::string required, but existing clients should move over to getConstantStringInfo instead. llvm-svn: 149351
* progress making the world safe to ConstantDataVector. WhileChris Lattner2012-01-261-16/+15
| | | | | | | | we're at it, allow PatternMatch's "neg" pattern to match integer vector negations, and enhance ComputeNumSigned bits to handle shl of vectors. llvm-svn: 149082
* use Constant::getAggregateElement to simplify a bunch of code.Chris Lattner2012-01-251-13/+6
| | | | llvm-svn: 148934
* Use the right method to get the # elements in a CDS.Chris Lattner2012-01-251-1/+1
| | | | llvm-svn: 148897
* teach valuetracking about ConstantDataSequentialChris Lattner2012-01-241-31/+47
| | | | llvm-svn: 148790
* Generalize isSafeToSpeculativelyExecute to work on arbitraryDan Gohman2012-01-041-1/+5
| | | | | | | Values, rather than just Instructions, since it's interesting for ConstantExprs too. llvm-svn: 147560
* PatternMatch: Introduce a matcher for instructions with the "exact" bit. Use ↵Benjamin Kramer2012-01-011-9/+5
| | | | | | it to simplify a few matchers. llvm-svn: 147403
* ComputeMaskedBits: Make knownzero computation more aggressive for ctlz with ↵Benjamin Kramer2011-12-241-1/+8
| | | | | | | | | undef zero. unsigned foo(unsigned x) { return 31 - __builtin_clz(x); } now compiles into a single "bsrl" instruction on x86. llvm-svn: 147255
* Make some intrinsics safe to speculatively execute.Nick Lewycky2011-12-211-4/+24
| | | | llvm-svn: 147036
* Move Instruction::isSafeToSpeculativelyExecute out of VMCore andDan Gohman2011-12-141-0/+61
| | | | | | | | | into Analysis as a standalone function, since there's no need for it to be in VMCore. Also, update it to use isKnownNonZero and other goodies available in Analysis, making it more precise, enabling more aggressive optimization. llvm-svn: 146610
* Probably not a good idea to convert a single vector load into a memcpy. WeChad Rosier2011-12-061-0/+2
| | | | | | | | don't do this now, but add a test case to prevent this from happening in the future. Additional test for rdar://9892684 llvm-svn: 145879
* Add support for vectors of pointers.Nadav Rotem2011-12-051-4/+6
| | | | llvm-svn: 145801
* Fix a theoretical problem (not seen in the wild): if different instances of aDuncan Sands2011-11-291-1/+1
| | | | | | | | | | | | | | | weak variable are compiled by different compilers, such as GCC and LLVM, while LLVM may increase the alignment to the preferred alignment there is no reason to think that GCC will use anything more than the ABI alignment. Since it is the GCC version that might end up in the final program (as the linkage is weak), it is wrong to increase the alignment of loads from the global up to the preferred alignment as the alignment might only be the ABI alignment. Increasing alignment up to the ABI alignment might be OK, but I'm not totally convinced that it is. It seems better to just leave the alignment of weak globals alone. llvm-svn: 145413
* Make SelectionDAG::InferPtrAlignment use llvm::ComputeMaskedBits instead of ↵Eli Friedman2011-11-281-8/+10
| | | | | | duplicating the logic for globals. Make llvm::ComputeMaskedBits handle GlobalVariables slightly more aggressively, to match what InferPtrAlignment knew how to do. llvm-svn: 145304
* Fix a crash in which a multiplication was being reported as being both negativeDuncan Sands2011-11-231-2/+7
| | | | | | | | and positive: positive, because it could be directly computed to be positive; negative, because the nsw flags means it is either negative or undefined (the multiplication always overflowed). llvm-svn: 145104
* A shift of a power of two is a power of two or zero.Duncan Sands2011-10-281-1/+6
| | | | | | For completeness - not spotted in the wild. llvm-svn: 143211
* Reapply commit 143028 with a fix: the problem was casting a ConstantExpr MulDuncan Sands2011-10-271-7/+49
| | | | | | | | | | | using BinaryOperator (which only works for instructions) when it should have been a cast to OverflowingBinaryOperator (which also works for constants). While there, correct a few other dubious looking uses of BinaryOperator. Thanks to Chad Rosier for the testcase. Original commit message: My super-optimizer noticed that we weren't folding this expression to true: (x *nsw x) sgt 0, where x = (y | 1). This occurs in 464.h264ref. llvm-svn: 143125
* Revert Duncan's r143028 expression folding which appears to be the culpritBob Wilson2011-10-271-46/+4
| | | | | | behind a compile failure on 483.xalancbmk. llvm-svn: 143102
* The maximum power of 2 dividing a power of 2 is itself. This occursDuncan Sands2011-10-261-10/+27
| | | | | | in 403.gcc and was spotted by my super-optimizer. llvm-svn: 143054
* My super-optimizer noticed that we weren't folding this expression toDuncan Sands2011-10-261-4/+46
| | | | | | true: (x *nsw x) sgt 0, where x = (y | 1). This occurs in 464.h264ref. llvm-svn: 143028
* "@string = constant i8 0" is a value i8* string of length zero. Analyze thatNick Lewycky2011-10-201-6/+13
| | | | | | correctly in GetStringLength, fixing PR11181! llvm-svn: 142558
* Migrate LLVM and Clang to use the new makeArrayRef(...) functions where ↵Frits van Bommel2011-07-181-6/+3
| | | | | | | | previously explicit non-default constructors were used. Mostly mechanical with some manual reformatting. llvm-svn: 135390
* land David Blaikie's patch to de-constify Type, with a few tweaks.Chris Lattner2011-07-181-15/+15
| | | | llvm-svn: 135375
* Convert InsertValueInst and ExtractValueInst APIs to use ArrayRef.Jay Foad2011-07-131-31/+28
| | | | llvm-svn: 135040
* Move onlyUsedByLifetimeMarkers to ValueTracking so that it can be used by otherNick Lewycky2011-06-271-0/+16
| | | | | | passes as well. llvm-svn: 133904
* Renamed llvm.x86.sse42.crc32 intrinsics; crc64 doesn't exist. Chad Rosier2011-05-261-2/+2
| | | | | | | crc32.[8|16|32] have been renamed to .crc32.32.[8|16|32] and crc64.[8|16|32] have been renamed to .crc32.64.[8|64]. llvm-svn: 132163
* Teach valuetracking that byval arguments with a specified alignment areChris Lattner2011-05-231-1/+11
| | | | | | | | | | | | | | | | | | | | | | aligned. Teach memcpyopt to not give up all hope when confonted with an underaligned memcpy feeding an overaligned byval. If the *source* of the memcpy can be determined to be adequeately aligned, or if it can be forced to be, we can eliminate the memcpy. This addresses PR9794. We now compile the example into: define i32 @f(%struct.p* nocapture byval align 8 %q) nounwind ssp { entry: %call = call i32 @g(%struct.p* byval align 8 %q) nounwind ret i32 %call } in both x86-64 and x86-32 mode. We still don't get a tailcall though, because tailcalls apparently can't handle byval. llvm-svn: 131884
* Teach ValueTracking about x86 crc32 intrinsics.Evan Cheng2011-05-221-0/+4
| | | | llvm-svn: 131861
* Fix a ton of comment typos found by codespell. Patch byChris Lattner2011-04-151-2/+2
| | | | | | Luis Felipe Strano Moraes! llvm-svn: 129558
* Don't assume something which might be a constant expression is an instruction.Eli Friedman2011-04-021-3/+3
| | | | | | | Based on PR9429, but no testcase because I can't figure out how to trigger it anymore given other changes to the relevant code. llvm-svn: 128781
* Fix INT_MIN gotcha pointed out by Eli Friedman.Nick Lewycky2011-03-211-3/+4
| | | | llvm-svn: 128028
* Teach ComputeMaskedBits about sub nsw.Benjamin Kramer2011-03-121-8/+16
| | | | llvm-svn: 127548
* ComputeMaskedBits: sub falls through to add, and sub doesn't have the same ↵Benjamin Kramer2011-03-111-1/+2
| | | | | | | | overflow semantics as add. Should fix the selfhost failures that started with r127463. llvm-svn: 127465
* Teach ComputeMaskedBits about nsw on add. I don't think there's anything we canNick Lewycky2011-03-111-0/+14
| | | | | | | do with nuw here, but sub and mul should be given similar treatment. Fixes PR9343 #15! llvm-svn: 127463
* Fix PR9331. Simplified version of a patch by Jakub Staszak.Duncan Sands2011-03-081-0/+4
| | | | llvm-svn: 127243
* Add more analysis of the sign bit of an srem instruction. If the LHS is negativeNick Lewycky2011-03-071-0/+13
| | | | | | | then the result could go either way. If it's provably positive then so is the srem. Fixes PR9343 #7! llvm-svn: 127146
* Fix comment.Nick Lewycky2011-02-281-1/+1
| | | | llvm-svn: 126645
* srem doesn't actually have the same resulting sign as its numerator, you couldNick Lewycky2011-02-281-12/+0
| | | | | | | also have a zero when numerator = denominator. Reverts parts of r126635 and r126637. llvm-svn: 126644
* Teach value tracking to make use of flags in more situations.Nick Lewycky2011-02-281-0/+25
| | | | llvm-svn: 126642
* Teach ValueTracking to look at the dividend when determining the sign bit of anNick Lewycky2011-02-281-0/+12
| | | | | | srem instruction. llvm-svn: 126637
OpenPOWER on IntegriCloud