summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis
Commit message (Collapse)AuthorAgeFilesLines
...
* [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
* ValueTracking: Handle canonicalize in CannotBeNegativeZeroMatt Arsenault2018-08-061-0/+1
| | | | | | | Also fix apparently missing test coverage for any of the handling here. llvm-svn: 339023
* Re-enable "[ValueTracking] Teach isKnownNonNullFromDominatingCondition about ↵Max Kazantsev2018-08-061-10/+33
| | | | | | | | | | | AND" The patch was reverted because of bug detected by sanitizer. The bug is fixed, respective tests added. Differential Revision: https://reviews.llvm.org/D50172 llvm-svn: 339005
* Revert rL338990 to see if it causes sanitizer failuresMax Kazantsev2018-08-061-28/+10
| | | | | | | | | Multiple failues reported by sanitizer-x86_64-linux, seem to be caused by this patch. Reverting to see if they sustain without it. Differential Revision: https://reviews.llvm.org/D50172 llvm-svn: 338994
* [ValueTracking] Teach isKnownNonNullFromDominatingCondition about ANDMax Kazantsev2018-08-061-10/+28
| | | | | | | | | | | `isKnownNonNullFromDominatingCondition` is able to prove non-null basing on `br` or `guard` by `%p != null` condition, but is unable to do so basing on `(%p != null) && %other_cond`. This patch allows it to do so. Differential Revision: https://reviews.llvm.org/D50172 Reviewed By: reames llvm-svn: 338990
* Enrich inline messagesDavid Bolvansky2018-08-051-36/+57
| | | | | | | | | | | | | | | | | | | | | | Summary: This patch improves Inliner to provide causes/reasons for negative inline decisions. 1. It adds one new message field to InlineCost to report causes for Always and Never instances. All Never and Always instantiations must provide a simple message. 2. Several functions that used to return the inlining results as boolean are changed to return InlineResult which carries the cause for negative decision. 3. Changed remark priniting and debug output messages to provide the additional messages and related inline cost. 4. Adjusted tests for changed printing. Patch by: yrouban (Yevgeny Rouban) Reviewers: craig.topper, sammccall, sgraenitz, NutshellySima, shchenz, chandlerc, apilipenko, javed.absar, tejohnson, dblaikie, sanjoy, eraman, xbolva00 Reviewed By: tejohnson, xbolva00 Subscribers: xbolva00, llvm-commits, arsenm, mehdi_amini, eraman, haicheng, steven_wu, dexonsmith Differential Revision: https://reviews.llvm.org/D49412 llvm-svn: 338969
* [InstSimplify] fold extracting from std::pair (2/2)Hiroshi Inoue2018-08-031-0/+34
| | | | | | | | | | | This is the second patch of the series which intends to enable jump threading for an inlined method whose return type is std::pair<int, bool> or std::pair<bool, int>. The first patch is https://reviews.llvm.org/rL338485. This patch handles code sequences that merges two values using `shl` and `or`, then extracts one value using `and`. Differential Revision: https://reviews.llvm.org/D49981 llvm-svn: 338817
* [SCEV] Properly solve quadratic equationsKrzysztof Parzyszek2018-08-021-106/+258
| | | | | | Differential Revision: https://reviews.llvm.org/D48283 llvm-svn: 338758
* [InstSimplify] move minnum/maxnum with undef fold from instcombineSanjay Patel2018-08-021-3/+4
| | | | llvm-svn: 338719
* [ValueTracking] fix maxnum miscompile for cannotBeOrderedLessThanZero (PR37776)Sanjay Patel2018-08-021-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds the NAN checks suggested in PR37776: https://bugs.llvm.org/show_bug.cgi?id=37776 If both operands to maxnum are NAN, that should get constant folded, so we don't have to handle that case. This is the same assumption as other FP ops in this function. Returning 'false' is always conservatively correct. Copying from the bug report: Currently, we have this for "when is cannotBeOrderedLessThanZero (mustBePositiveOrNaN) true for maxnum": L ------------------- | Pos | Neg | NaN | ------------------------ |Pos | x | x | x | ------------------------ R |Neg | x | | x | ------------------------ |NaN | x | x | x | ------------------------ The cases with (Neg & NaN) are wrong. We should have: L ------------------- | Pos | Neg | NaN | ------------------------ |Pos | x | x | x | ------------------------ R |Neg | x | | | ------------------------ |NaN | x | | x | ------------------------ Differential Revision: https://reviews.llvm.org/D50081 llvm-svn: 338716
* [InstSimplify] move minnum/maxnum with same arg fold from instcombineSanjay Patel2018-08-011-0/+3
| | | | llvm-svn: 338652
* Revert "Enrich inline messages", tests failDavid Bolvansky2018-08-011-57/+36
| | | | llvm-svn: 338496
* Enrich inline messagesDavid Bolvansky2018-08-011-36/+57
| | | | | | | | | | | | | | | | | | | | | | Summary: This patch improves Inliner to provide causes/reasons for negative inline decisions. 1. It adds one new message field to InlineCost to report causes for Always and Never instances. All Never and Always instantiations must provide a simple message. 2. Several functions that used to return the inlining results as boolean are changed to return InlineResult which carries the cause for negative decision. 3. Changed remark priniting and debug output messages to provide the additional messages and related inline cost. 4. Adjusted tests for changed printing. Patch by: yrouban (Yevgeny Rouban) Reviewers: craig.topper, sammccall, sgraenitz, NutshellySima, shchenz, chandlerc, apilipenko, javed.absar, tejohnson, dblaikie, sanjoy, eraman, xbolva00 Reviewed By: tejohnson, xbolva00 Subscribers: xbolva00, llvm-commits, arsenm, mehdi_amini, eraman, haicheng, steven_wu, dexonsmith Differential Revision: https://reviews.llvm.org/D49412 llvm-svn: 338494
* [InstSimplify] fold extracting from std::pair (1/2)Hiroshi Inoue2018-08-011-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch intends to enable jump threading when a method whose return type is std::pair<int, bool> or std::pair<bool, int> is inlined. For example, jump threading does not happen for the if statement in func. std::pair<int, bool> callee(int v) { int a = dummy(v); if (a) return std::make_pair(dummy(v), true); else return std::make_pair(v, v < 0); } int func(int v) { std::pair<int, bool> rc = callee(v); if (rc.second) { // do something } SROA executed before the method inlining replaces std::pair by i64 without splitting in both callee and func since at this point no access to the individual fields is seen to SROA. After inlining, jump threading fails to identify that the incoming value is a constant due to additional instructions (like or, and, trunc). This series of patch add patterns in InstructionSimplify to fold extraction of members of std::pair. To help jump threading, actually we need to optimize the code sequence spanning multiple BBs. These patches does not handle phi by itself, but these additional patterns help NewGVN pass, which calls instsimplify to check opportunities for simplifying instructions over phi, apply phi-of-ops optimization to result in successful jump threading. SimplifyDemandedBits in InstCombine, can do more general optimization but this patch aims to provide opportunities for other optimizers by supporting a simple but common case in InstSimplify. This first patch in the series handles code sequences that merges two values using shl and or and then extracts one value using lshr. Differential Revision: https://reviews.llvm.org/D48828 llvm-svn: 338485
* Revert Enrich inline messagesDavid Bolvansky2018-07-311-57/+36
| | | | llvm-svn: 338389
* Enrich inline messagesDavid Bolvansky2018-07-311-36/+57
| | | | | | | | | | | | | | | | | | | | | | Summary: This patch improves Inliner to provide causes/reasons for negative inline decisions. 1. It adds one new message field to InlineCost to report causes for Always and Never instances. All Never and Always instantiations must provide a simple message. 2. Several functions that used to return the inlining results as boolean are changed to return InlineResult which carries the cause for negative decision. 3. Changed remark priniting and debug output messages to provide the additional messages and related inline cost. 4. Adjusted tests for changed printing. Patch by: yrouban (Yevgeny Rouban) Reviewers: craig.topper, sammccall, sgraenitz, NutshellySima, shchenz, chandlerc, apilipenko, javed.absar, tejohnson, dblaikie, sanjoy, eraman, xbolva00 Reviewed By: tejohnson, xbolva00 Subscribers: xbolva00, llvm-commits, arsenm, mehdi_amini, eraman, haicheng, steven_wu, dexonsmith Differential Revision: https://reviews.llvm.org/D49412 llvm-svn: 338387
* [MemDep] Use PhiValuesAnalysis to improve alias analysis resultsJohn Brawn2018-07-311-3/+14
| | | | | | | | | | This is being done in order to make GVN able to better optimize certain inputs. MemDep doesn't use PhiValues directly, but does need to notifiy it when things get invalidated. Differential Revision: https://reviews.llvm.org/D48489 llvm-svn: 338384
* [InstSimplify] Fold another Select with And/Or patternDavid Bolvansky2018-07-311-14/+22
| | | | | | | | | | | | | | Summary: Proof: https://rise4fun.com/Alive/L5J Reviewers: lebedev.ri, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49975 llvm-svn: 338383
* Remove trailing spaceFangrui Song2018-07-3013-118/+118
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338293
* [BasicAA] Use PhiValuesAnalysis if available when handling phi aliasJohn Brawn2018-07-301-25/+67
| | | | | | | | | | | | | | | | By using PhiValuesAnalysis we can get all the values reachable from a phi, so we can be more precise instead of giving up when a phi has phi operands. We can't make BaseicAA directly use PhiValuesAnalysis though, as the user of BasicAA may modify the function in ways that PhiValuesAnalysis can't cope with. For this optional usage to work correctly BasicAAWrapperPass now needs to be not marked as CFG-only (i.e. it is now invalidated even when CFG is preserved) due to how the legacy pass manager handles dependent passes being invalidated, namely the depending pass still has a pointer to the now-dead dependent pass. Differential Revision: https://reviews.llvm.org/D44564 llvm-svn: 338242
OpenPOWER on IntegriCloud