summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis
Commit message (Collapse)AuthorAgeFilesLines
...
* [MemorySSA] Add expesive check for validating clobber accesses.Alina Sbirlea2018-08-291-11/+45
| | | | | | | | | | | | Summary: Add validation of clobber accesses as expensive check. Reviewers: george.burgess.iv Subscribers: sanjoy, jlebar, Prazek, llvm-commits Differential Revision: https://reviews.llvm.org/D51327 llvm-svn: 340951
* Revert r340921 "[NFC] Unify guards detection"Hans Wennborg2018-08-292-4/+4
| | | | | | | | | | | | | | | | | | This broke the build, see e.g. http://lab.llvm.org:8011/builders/clang-cmake-armv8-lnt/builds/4626/ http://lab.llvm.org:8011/builders/clang-ppc64be-linux-lnt/builds/18647/ http://lab.llvm.org:8011/builders/clang-cmake-x86_64-avx2-linux/builds/5856/ http://lab.llvm.org:8011/builders/lld-x86_64-freebsd/builds/22800/ > We have multiple places in code where we try to identify whether or not > some instruction is a guard. This patch factors out this logic into a separate > utility function which works uniformly in all places. > > Differential Revision: https://reviews.llvm.org/D51152 > Reviewed By: fedor.sergeev llvm-svn: 340923
* [NFC] Unify guards detectionMax Kazantsev2018-08-292-4/+4
| | | | | | | | | | | We have multiple places in code where we try to identify whether or not some instruction is a guard. This patch factors out this logic into a separate utility function which works uniformly in all places. Differential Revision: https://reviews.llvm.org/D51152 Reviewed By: fedor.sergeev llvm-svn: 340921
* [NFC][PassTiming] factor out generic PassTimingInfoFedor Sergeev2018-08-283-0/+3
| | | | | | | | Moving PassTimingInfo from legacy pass manager code into a separate header. Making it suitable for both legacy and new pass manager. Adding a test on -time-passes main functionality. llvm-svn: 340872
* Fix in getAllocationDataForFunctionDavid Chisnall2018-08-281-1/+1
| | | | | | | | | | | | | | | | Summary: Correct to use set like behaviour of AllocType. Should check for subset, not precise value. Reviewers: theraven Reviewed By: theraven Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D50959 llvm-svn: 340807
* [MemorySSA] Add NDEBUG checks to verifiers; NFCGeorge Burgess IV2018-08-281-0/+4
| | | | | | | | verify*() methods are intended to have no side-effects (unless we detect broken MSSA, in which case they assert()), and all of the other verify methods are wrapped by `#ifndef NDEBUG`. llvm-svn: 340793
* Revert "[SCEV][NFC] Check NoWrap flags before lexicographical comparison of ↵Roman Tereshin2018-08-271-8/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SCEVs" This reverts r319889. Unfortunately, wrapping flags are not a part of SCEV's identity (they do not participate in computing a hash value or in equality comparisons) and in fact they could be assigned after the fact w/o rebuilding a SCEV. Grep for const_cast's to see quite a few of examples, apparently all for AddRec's at the moment. So, if 2 expressions get built in 2 slightly different ways: one with flags set in the beginning, the other with the flags attached later on, we may end up with 2 expressions which are exactly the same but have their operands swapped in one of the commutative N-ary expressions, and at least one of them will have "sorted by complexity" invariant broken. 2 identical SCEV's won't compare equal by pointer comparison as they are supposed to. A real-world reproducer is added as a regression test: the issue described causes 2 identical SCEV expressions to have different order of operands and therefore compare not equal, which in its turn prevents LoadStoreVectorizer from vectorizing a pair of consecutive loads. On a larger example (the source of the test attached, which is a bugpoint) I have seen even weirder behavior: adding a constant to an existing SCEV changes the order of the existing terms, for instance, getAddExpr(1, ((A * B) + (C * D))) returns (1 + (C * D) + (A * B)). Differential Revision: https://reviews.llvm.org/D40645 llvm-svn: 340777
* [IR] Replace `isa<TerminatorInst>` with `isTerminator()`.Chandler Carruth2018-08-264-6/+6
| | | | | | | | | | | | This is a bit awkward in a handful of places where we didn't even have an instruction and now we have to see if we can build one. But on the whole, this seems like a win and at worst a reasonable cost for removing `TerminatorInst`. All of this is part of the removal of `TerminatorInst` from the `Instruction` type hierarchy. llvm-svn: 340701
* [IR] Begin removal of TerminatorInst by removing successor manipulation.Chandler Carruth2018-08-262-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The core get and set routines move to the `Instruction` class. These routines are only valid to call on instructions which are terminators. The iterator and *generic* range based access move to `CFG.h` where all the other generic successor and predecessor access lives. While moving the iterator here, simplify it using the iterator utilities LLVM provides and updates coding style as much as reasonable. The APIs remain pointer-heavy when they could better use references, and retain the odd behavior of `operator*` and `operator->` that is common in LLVM iterators. Adjusting this API, if desired, should be a follow-up step. Non-generic range iteration is added for the two instructions where there is an especially easy mechanism and where there was code attempting to use the range accessor from a specific subclass: `indirectbr` and `br`. In both cases, the successors are contiguous operands and can be easily iterated via the operand list. This is the first major patch in removing the `TerminatorInst` type from the IR's instruction type hierarchy. This change was discussed in an RFC here and was pretty clearly positive: http://lists.llvm.org/pipermail/llvm-dev/2018-May/123407.html There will be a series of much more mechanical changes following this one to complete this move. Differential Revision: https://reviews.llvm.org/D47467 llvm-svn: 340698
* [PhiValues] Use callback value handles to invalidate deleted valuesJohn Brawn2018-08-241-0/+17
| | | | | | | | | | | The way that PhiValues is integrated with BasicAA it is possible for a pass which uses BasicAA to pick up an instance of BasicAA that uses PhiValues without intending to, and then delete values from a function in a way that causes PhiValues to return dangling pointers to these deleted values. Fix this by having a set of callback value handles to invalidate values when they're deleted. llvm-svn: 340613
* [ValueTracking] Fix assert message and add test case for r340546 and PR38677.Craig Topper2018-08-231-1/+1
| | | | | | The bug was already fixed. This just adds a test case for it. llvm-svn: 340556
* [ValueTracking] Fix an assert from r340480.Craig Topper2018-08-231-1/+3
| | | | | | | | | | We need to allow ConstantExpr Selects in addition to SelectInst. I'll try to put together a test case, but I wanted to fix the issues being reported. Fixes PR38677 llvm-svn: 340546
* [ValueTracking] Teach computeNumSignBits to understand min/max clamp ↵Craig Topper2018-08-221-1/+37
| | | | | | | | | | patterns with constant/splat values If we have a min/max pair we can do a better job of counting sign bits if we look at them together. This is similar to what is done in the SelectionDAG version of computeNumSignBits for ISD::SMAX/SMIN. Differential Revision: https://reviews.llvm.org/D51112 llvm-svn: 340480
* [MemorySSA] Invalidate optimized Defs upon moving them; NFCGeorge Burgess IV2018-08-221-5/+14
| | | | | | | | | | | | | | | | | We're currently getting this behavior implicitly, since we determine if a Def's optimization is valid based on the ID of its defining access. This is incorrect, though I wouldn't be surprised if this was masked in part by that we're using a WeakVH to track what Defs are optimized to. (Not to mention that we don't move Defs super often, AFAICT). I'll submit a patch to fix this shortly. This also includes a minor refactor to reduce duplication a bit. No test is included, since like said, this already happens to be our behavior. I'll add a test for this with my fix to the other bug mentioned above. llvm-svn: 340461
* [AA] Remove a needless variable [NFC]Philip Reames2018-08-221-3/+1
| | | | | | There's no need to track a seperate variable for argmemonly aliasing. This falls out naturally of the modinfo union. Note that we may return earlier than we would have earlier if all arguments are explicitly readnone. The overall result doesn't change, just how we get there. llvm-svn: 340443
* [AST] Minor whitespace cleanup [NFC]Philip Reames2018-08-221-11/+7
| | | | llvm-svn: 340440
* [MemorySSA] Move two simple getters; NFCGeorge Burgess IV2018-08-221-8/+0
| | | | | | | | We're calling these functions quite a bit from outside of MemorySSA.cpp now. Given that they're relatively simple one-liners, I think the style preference is to have them inline. llvm-svn: 340430
* [AST] Fix a whitespace typo [NFC]Philip Reames2018-08-221-1/+1
| | | | llvm-svn: 340384
* [AST] Reorder code to reduce a future patch diff [NFC]Philip Reames2018-08-221-3/+3
| | | | llvm-svn: 340383
* [AST] Move a function definition into the cpp [NFC]Philip Reames2018-08-221-0/+12
| | | | llvm-svn: 340382
* [AST] Remove notion of volatile from alias sets [NFCI]Philip Reames2018-08-211-24/+8
| | | | | | | | | | Volatility is not an aliasing property. We used to model volatile as if it had extremely conservative aliasing implications, but that hasn't been true for several years now. So, it doesn't make sense to be in AliasSet. It also turns out the code is entirely a noop. Outside of the AST code to update it, there was only one user: load store promotion in LICM. L/S promotion doesn't need the check since it walks all the users of the address anyway. It already checks each load or store via !isUnordered which causes us to bail for volatile accesses. (Look at the lines immediately following the two remove asserts.) There is the possibility of some small compile time impact here, but the only case which will get noticeably slower is a loop with a large number of loads and stores to the same address where only the last one we inspect is volatile. This is sufficiently rare it's not worth optimizing for.. llvm-svn: 340312
* [InstSimplify] use isKnownNeverNaN to fold more fcmp ord/unoSanjay Patel2018-08-211-7/+5
| | | | | | | | | | | Remove duplicate tests from InstCombine that were added with D50582. I left negative tests there to verify that nothing in InstCombine tries to go overboard. If isKnownNeverNaN is improved to handle the FP binops or other cases, we should have coverage under InstSimplify, so we could remove more duplicate tests from InstCombine at that time. llvm-svn: 340279
* [NFC] Factor out predecessors collection into a separate methodMax Kazantsev2018-08-211-11/+20
| | | | | | | | | It may be reused in a different piece of logic. Differential Revision: https://reviews.llvm.org/D50890 Reviewed By: reames llvm-svn: 340250
* [AST] Mark invariant.starts as being readonlyPhilip Reames2018-08-211-1/+2
| | | | | | | | These intrinsics are modelled as writing for control flow purposes, but they don't actually write to any location. Marking these - as we did for guards - allows LICM to hoist loads out of loops containing invariant.starts. Differential Revision: https://reviews.llvm.org/D50861 llvm-svn: 340245
* ValueTracking: Handle more instructions in isKnownNeverNaNMatt Arsenault2018-08-201-3/+33
| | | | llvm-svn: 340187
* [AST] Clarify printing of unknown size locations [NFC]Philip Reames2018-08-171-1/+4
| | | | | | Printing "unknown" is much more clear than an arbitrary large integer llvm-svn: 340108
* [IDF] Teach Iterated Dominance Frontier to use a snapshot CFG based on a ↵Alina Sbirlea2018-08-171-5/+16
| | | | | | | | | | | | | | | | GraphDiff. Summary: Create the ability to compute IDF using a CFG View. For this, we'll need a new DT created using a list of Updates (to be refactored later to a GraphDiff), and the GraphTraits based on the same GraphDiff. Reviewers: kuhar, george.burgess.iv, mzolotukhin Subscribers: sanjoy, jlebar, llvm-commits Differential Revision: https://reviews.llvm.org/D50675 llvm-svn: 340052
* [InstrSimplify,NewGVN] Add option to ignore additional instr info when ↵Florian Hahn2018-08-172-155/+188
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | simplifying. NewGVN uses InstructionSimplify for simplifications of leaders of congruence classes. It is not guaranteed that the metadata or other flags/keywords (like nsw or exact) of the leader is available for all members in a congruence class, so we cannot use it for simplification. This patch adds a InstrInfoQuery struct with a boolean field UseInstrInfo (which defaults to true to keep the current behavior as default) and a set of helper methods to get metadata/keywords for a given instruction, if UseInstrInfo is true. The whole thing might need a better name, to avoid confusion with TargetInstrInfo but I am not sure what a better name would be. The current patch threads through InstrInfoQuery to the required places, which is messier then it would need to be, if InstructionSimplify and ValueTracking would share the same Query struct. The reason I added it as a separate struct is that it can be shared between InstructionSimplify and ValueTracking's query objects. Also, some places do not need a full query object, just the InstrInfoQuery. It also updates some interfaces that do not take a Query object, but a set of optional parameters to take an additional boolean UseInstrInfo. See https://bugs.llvm.org/show_bug.cgi?id=37540. Reviewers: dberlin, davide, efriedma, sebpop, hiraditya Reviewed By: hiraditya Differential Revision: https://reviews.llvm.org/D47143 llvm-svn: 340031
* [ConstantFolding] add simplifications for funnel shift intrinsicsSanjay Patel2018-08-171-0/+25
| | | | | | | | | | | This is another step towards being able to canonicalize to the funnel shift intrinsics in IR (see D49242 for the initial patch). We should not have any loss of simplification power in IR between these and the equivalent IR constructs. Differential Revision: https://reviews.llvm.org/D50848 llvm-svn: 340022
* [MustExecute] Fix algorithmic bug in isGuaranteedToExecute. PR38514Max Kazantsev2018-08-171-33/+70
| | | | | | | | | | | | | | | | | | | | | The description of `isGuaranteedToExecute` does not correspond to its implementation. According to description, it should return `true` if an instruction is executed under the assumption that its loop is *entered*. However there is a sophisticated alrogithm inside that tries to prove that the instruction is executed if the loop is *exited*, which is not the same thing for infinite loops. There is an attempt to protect from dealing with infinite loops by prohibiting loops without exit blocks, however an infinite loop can have exit blocks. As result of that, MustExecute can falsely consider some blocks that are never entered as mustexec, and LICM can hoist dangerous instructions out of them basing on this fact. This may introduce UB to programs which did not contain it initially. This patch removes the problematic algorithm and replaced it with a one which tries to prove what is required in description. Differential Revision: https://reviews.llvm.org/D50558 Reviewed By: reames llvm-svn: 339984
* [MemLoc] Fix a bug causing any use of invariant.end to crash in LICMPhilip Reames2018-08-161-0/+4
| | | | | | The fix is fairly simple, but is says something unpleasant about the usage and testing of invariant.start/end scopes that this went undetected. To put this in perspective, *any* invariant.end in a loop flowing through LICM crashed. I haven't bothered to figure out just how far back this goes, but it's not caused by any of the recent changes. We're probably talking months if not years. llvm-svn: 339936
* [LICM][NFC] Restructure pointer invalidation API in terms of MemoryLocationPhilip Reames2018-08-161-6/+7
| | | | | | | | Main value is just simplifying code. I'll further simply the argument handling case in a bit, but that involved a slightly orthogonal change so I went with the mildy ugly intermediate for this patch. Note that the isSized check in the old LICM code was not carried across. It turns out that check was dead. a) no test exercised it, and b) langref and verifier had been updated to disallow unsized types used in loads. llvm-svn: 339930
* [NFC] Add missing const modifierMax Kazantsev2018-08-161-1/+1
| | | | llvm-svn: 339844
* [BFI] Use rounding while computing profile counts.Easwaran Raman2018-08-161-1/+3
| | | | | | | | | | | | | | | Summary: Profile count of a block is computed by multiplying its block frequency by entry count and dividing the result by entry block frequency. Do rounded division in the last step and update test cases appropriately. Reviewers: davidxl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D50822 llvm-svn: 339835
* [MemorySSA] Expose the verify as a debug option.Alina Sbirlea2018-08-151-3/+9
| | | | | | | | | | | | Summary: Expose VerifyMemorySSA as a debug option. If set, passes will call the MSSA->verifyMemorySSA() after calling into the updater's APIs when MemorySSA should be valid. Reviewers: george.burgess.iv Subscribers: sanjoy, jlebar, Prazek, llvm-commits Differential Revision: https://reviews.llvm.org/D50749 llvm-svn: 339795
* [AliasSetTracker] Do not treat experimental_guard intrinsic as memory ↵Max Kazantsev2018-08-151-1/+7
| | | | | | | | | | | | | | | | writing instruction The `experimental_guard` intrinsic has memory write semantics to model the thread-exiting logic, but does not do any actual writes to memory. Currently, `AliasSetTracker` treats it as a normal memory write. As result, a loop-invariant load cannot be hoisted out of loop because the guard may possibly alias with it. This patch makes `AliasSetTracker` so that it doesn't treat guards as memory writes. Differential Revision: https://reviews.llvm.org/D50497 Reviewed By: reames llvm-svn: 339753
* [NFC] Refactoring of LoopSafetyInfo, step 1Max Kazantsev2018-08-151-18/+17
| | | | | | | | | Turn structure into class, encapsulate methods, add clarifying comments. Differential Revision: https://reviews.llvm.org/D50693 Reviewed By: reames llvm-svn: 339752
* [BasicAA] Don't assume tail calls with byval don't alias allocasReid Kleckner2018-08-141-6/+7
| | | | | | | | | | | | | | | | | | | | Summary: Calls marked 'tail' cannot read or write allocas from the current frame because the current frame might be destroyed by the time they run. However, a tail call may use an alloca with byval. Calling with byval copies the contents of the alloca into argument registers or stack slots, so there is no lifetime issue. Tail calls never modify allocas, so we can return just ModRefInfo::Ref. Fixes PR38466, a longstanding bug. Reviewers: hfinkel, nlewycky, gbiv, george.burgess.iv Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D50679 llvm-svn: 339636
* [AST] Minor formatting cleanup [NFC]Philip Reames2018-08-131-8/+4
| | | | llvm-svn: 339627
* [AST] Cleanup code by using MemoryLocation utility [NFC]Philip Reames2018-08-131-43/+11
| | | | | | Differential Revision: https://reviews.llvm.org/D50588 llvm-svn: 339625
* [X86] Add constant folding for AVX512 versions of scalar floating point to ↵Craig Topper2018-08-121-5/+76
| | | | | | | | | | | | | | | | | | | integer conversion intrinsics. Summary: We've supported constant folding for sse versions for many years. This patch adds support for the avx512 versions including unsigned with the default rounding mode. We could probably do more with other roundings modes and SAE in the future. The test cases are largely based on the sse.ll test cases. But I did add some test cases to ensure the unsigned versions don't accept negative values. Also checked the bounds of f64->i32 conversions to make sure unsigned has a larger positive range than signed. Reviewers: RKSimon, spatel, chandlerc Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D50553 llvm-svn: 339529
* [InstSimplify] Guard against large shift amounts.Benjamin Kramer2018-08-121-3/+3
| | | | | | | These are always UB, but can happen for large integer inputs. Testing it is very fragile as -simplifycfg will nuke the UB top-down. llvm-svn: 339515
* [MemorySSA] "Fix" lifetime intrinsic handlingGeorge Burgess IV2018-08-101-2/+7
| | | | | | | | | | | | | | | | | | | MemorySSA currently creates MemoryAccesses for lifetime intrinsics, and sometimes treats them as clobbers. This may/may not be the best way forward, but while we're doing it, we should consider MayAlias/PartialAlias to be clobbers. The ideal fix here is probably to remove all of this reasoning about lifetimes from MemorySSA + put it into the passes that need to care. But that's a wayyy broader fix that needs some consensus, and we have miscompiles + a release branch today, and this should solve the miscompiles just as well. differential revision is D43269. Landing without an explicit LGTM (and without using the special please-autoclose-this syntax) so we can still use that revision as a place to decide what the right fix here is. llvm-svn: 339411
* ValueTracking: Start enhancing isKnownNeverNaNMatt Arsenault2018-08-092-12/+32
| | | | llvm-svn: 339399
* [InstSimplify] move minnum/maxnum with Inf folds from instcombineSanjay Patel2018-08-091-1/+16
| | | | llvm-svn: 339396
* [InstSimplify] fold fsub+fadd with common operandSanjay Patel2018-08-071-0/+8
| | | | llvm-svn: 339176
* [InstSimplify] fold fadd+fsub with common operandSanjay Patel2018-08-071-1/+3
| | | | llvm-svn: 339174
* [InstSimplify] fold fsub+fsub with common operandSanjay Patel2018-08-071-0/+5
| | | | llvm-svn: 339171
* [SampleFDO] Fix a bug in getOrCompHotCountThreshold/getOrCompColdCountThresholdWei Mi2018-08-071-2/+2
| | | | | | | | | | | | getOrCompHotCountThreshold/getOrCompColdCountThreshold introduced in https://reviews.llvm.org/D45377 contain a bad mistake and will only return 1 or 0 instead of the true hot/cold cutoff value. The patch fixes the mistake. But the mistake seems not causing big performance difference according to internal server benchmarks testing. Differential Revision: https://reviews.llvm.org/D50370 llvm-svn: 339162
* [InstSimplify] move minnum/maxnum with common op fold from instcombineSanjay Patel2018-08-071-0/+11
| | | | llvm-svn: 339144
OpenPOWER on IntegriCloud