summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Scalar/EarlyCSE.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Move updating functions to MemorySSAUpdater.Daniel Berlin2017-02-221-2/+6
| | | | | | | | | | | | | | | Add updater to passes that now need it. Move around code in MemorySSA to expose needed functions. Summary: Mostly cleanup Reviewers: george.burgess.iv Subscribers: llvm-commits, Prazek Differential Revision: https://reviews.llvm.org/D30221 llvm-svn: 295887
* [EarlyCSE] Don't DSE across readnone functions that may throwSanjoy Das2017-01-171-6/+7
| | | | | | | | | | | | Summary: Depends on D28740 Reviewers: dberlin, chandlerc, hfinkel, majnemer Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D28741 llvm-svn: 292249
* [PM] Introduce an analysis set used to preserve all analyses overChandler Carruth2017-01-151-3/+1
| | | | | | | | | | | | | | | a function's CFG when that CFG is unchanged. This allows transformation passes to simply claim they preserve the CFG and analysis passes to check for the CFG being preserved to remove the fanout of all analyses being listed in all passes. I've gone through and removed or cleaned up as many of the comments reminding us to do this as I could. Differential Revision: https://reviews.llvm.org/D28627 llvm-svn: 292054
* [EarlyCSE] less else, more auto; NFCSanjay Patel2017-01-031-2/+2
| | | | llvm-svn: 290848
* Revert @llvm.assume with operator bundles (r289755-r289757)Daniel Jasper2016-12-191-5/+12
| | | | | | | This creates non-linear behavior in the inliner (see more details in r289755's commit thread). llvm-svn: 290086
* Remove the AssumptionCacheHal Finkel2016-12-151-12/+5
| | | | | | | | | After r289755, the AssumptionCache is no longer needed. Variables affected by assumptions are now found by using the new operand-bundle-based scheme. This new scheme is more computationally efficient, and also we need much less code... llvm-svn: 289756
* [EarlyCSE] Make MemorySSA memory dependency check more aggressive.Geoff Berry2016-10-251-16/+6
| | | | | | | | | | Now that MemorySSA keeps track of whether MemoryUses are optimized, use getClobberingMemoryAccess() to check MemoryUse memory dependencies since it should no longer be so expensive. This is a follow-up change to https://reviews.llvm.org/D25881 llvm-svn: 285080
* [EarlyCSE] Optimize MemoryPhis and reduce memory clobber queries w/ MemorySSAGeoff Berry2016-10-241-10/+44
| | | | | | | | | | | | | | | | | | | | | Summary: When using MemorySSA, re-optimize MemoryPhis when removing a store since this may create MemoryPhis with all identical arguments. Also, when using MemorySSA to check if two MemoryUses are reading from the same version of the heap, use the defining access instead of calling getClobberingAccess, since the latter can currently result in many more AA calls. Once the MemorySSA use optimization tracking changes are done, we can remove this limitation, which should result in more loads being CSE'd. Reviewers: dberlin Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D25881 llvm-svn: 284984
* Fix typo in comment, NFCNick Lewycky2016-09-071-1/+1
| | | | llvm-svn: 280774
* [EarlyCSE] Optionally use MemorySSA. NFC.Geoff Berry2016-08-311-17/+125
| | | | | | | | | | | | | | | | | Summary: Use MemorySSA, if requested, to do less conservative memory dependency checking. This change doesn't enable the MemorySSA enhanced EarlyCSE in the default pipelines, so should be NFC. Reviewers: dberlin, sanjoy, reames, majnemer Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D19821 llvm-svn: 280279
* [EarlyCSE] Allow forwarding a non-invariant load into an invariant load.Geoff Berry2016-08-311-5/+5
| | | | | | | | | | Reviewers: sanjoy Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D23935 llvm-svn: 280265
* [EarlyCSE] Teach about CSE'ing over invariant.start intrinsicsAnna Thomas2016-08-091-0/+13
| | | | | | | | | | | | | | Summary: Teach EarlyCSE about invariant.start intrinsic. Specifically, we can perform store-load, load-load forwarding over this call. Reviewers: majnemer, reames, dberlin, sanjoy Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D23268 llvm-svn: 278153
* Consistently use FunctionAnalysisManagerSean Silva2016-08-091-1/+1
| | | | | | | | | | | Besides a general consistently benefit, the extra layer of indirection allows the mechanical part of https://reviews.llvm.org/D23256 that requires touching every transformation and analysis to be factored out cleanly. Thanks to David for the suggestion. llvm-svn: 278077
* [EarlyCSE] Correctly handle simplified, but live, instructionsDavid Majnemer2016-07-291-2/+4
| | | | | | | | | Some instructions may have their uses replaced with a symbolic constant. However, the instruction may still have side effects which percludes it from being removed from the function. EarlyCSE treated such an instruction as if it were removed, resulting in PR28763. llvm-svn: 277114
* Reinstate r273711David Majnemer2016-06-251-5/+12
| | | | | | | | | | r273711 was reverted by r273743. The inliner needs to know about any call sites in the inlined function. These were obscured if we replaced a call to undef with an undef but kept the call around. This fixes PR28298. llvm-svn: 273753
* Revert r273711, it caused PR28298.Nico Weber2016-06-241-12/+5
| | | | llvm-svn: 273743
* SimplifyInstruction does not imply DCEDavid Majnemer2016-06-241-5/+12
| | | | | | | We cannot remove an instruction with no uses just because SimplifyInstruction succeeds. It may have side effects. llvm-svn: 273711
* [EarlyCSE] Minor cosmetic NFC changesSanjoy Das2016-06-161-2/+2
| | | | | | | - Avoid implicit conversion from pointer to bool - Add a comment when passing in a boolean value llvm-svn: 272955
* [EarlyCSE] Fold invariant loadsSanjoy Das2016-06-161-8/+22
| | | | | | | | Redundant invariant loads can be CSE'ed with very little extra effort over what early-cse already tracks, so it looks reasonable to make early-cse handle this case. llvm-svn: 272954
* [PM] Add missing caching of GlobalsAA to EarlyCSE.Davide Italiano2016-06-081-0/+1
| | | | llvm-svn: 272204
* [EarlyCSE] Change key type of AvailableCalls to Instruction*. NFCI.Geoff Berry2016-05-131-3/+4
| | | | llvm-svn: 269445
* [EarlyCSE] Rename a variable for clarity [NFC]Philip Reames2016-05-061-8/+8
| | | | llvm-svn: 268701
* Mark guards on true as "trivially dead"Sanjoy Das2016-04-291-9/+2
| | | | | | | | | This moves some logic added to EarlyCSE in rL268120 into `llvm::isInstructionTriviallyDead`. Adds a test case for DCE to demonstrate that passes other than EarlyCSE can now pick up on the new information. llvm-svn: 268126
* [EarlyCSE] Simplify guard intrinsicsSanjoy Das2016-04-291-0/+23
| | | | | | | | | | | | | | | | | | Summary: This change teaches EarlyCSE some basic properties of guard intrinsics: - Guard intrinsics read all memory, but don't write to any memory - After a guard has executed, the condition it was guarding on can be assumed to be true - Guard intrinsics on a constant `true` are no-ops Reviewers: reames, hfinkel Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D19578 llvm-svn: 268120
* [EarlyCSE] Change LoadValue field Value *Data to Instruction *Inst. NFC.Geoff Berry2016-04-281-9/+9
| | | | | | Made in preparation for adding MemorySSA support to EarlyCSE. llvm-svn: 267893
* [EarlyCSE] Sort includes. NFC.Geoff Berry2016-04-281-1/+1
| | | | | | | | | | Reviewers: mcrosier Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D19617 llvm-svn: 267890
* Fix typo in comment; NFCSanjoy Das2016-04-271-1/+1
| | | | llvm-svn: 267653
* Re-commit optimization bisect support (r267022) without new pass manager ↵Andrew Kaylor2016-04-221-1/+1
| | | | | | | | | | support. The original commit was reverted because of a buildbot problem with LazyCallGraph::SCC handling (not related to the OptBisect handling). Differential Revision: http://reviews.llvm.org/D19172 llvm-svn: 267231
* [EarlyCSE/CVP] Add stats for CVPs and make sure to account for any Changes.Chad Rosier2016-04-221-4/+9
| | | | llvm-svn: 267187
* [EarlyCSE] Don't add the overflow flags to the hashDavid Majnemer2016-04-221-9/+0
| | | | | | | | We take the intersection of overflow flags while CSE'ing. This permits us to consider two instructions with different overflow behavior to be replaceable. llvm-svn: 267153
* Revert "Initial implementation of optimization bisect support."Vedant Kumar2016-04-221-5/+1
| | | | | | | | This reverts commit r267022, due to an ASan failure: http://lab.llvm.org:8080/green/job/clang-stage2-cmake-RgSan_check/1549 llvm-svn: 267115
* [EarlyCSE] Take the intersection of flags on instructionsDavid Majnemer2016-04-221-10/+3
| | | | | | | | | | | | | EarlyCSE had inconsistent behavior with regards to flag'd instructions: - In some cases, it would pessimize if the available instruction had different flags by not performing CSE. - In other cases, it would miscompile if it replaced an instruction which had no flags with an instruction which has flags. Fix this by being more consistent with our flag handling by utilizing andIRFlags. llvm-svn: 267111
* Initial implementation of optimization bisect support.Andrew Kaylor2016-04-211-1/+5
| | | | | | | | | | | | This patch implements a optimization bisect feature, which will allow optimizations to be selectively disabled at compile time in order to track down test failures that are caused by incorrect optimizations. The bisection is enabled using a new command line option (-opt-bisect-limit). Individual passes that may be skipped call the OptBisect object (via an LLVMContext) to see if they should be skipped based on the bisect limit. A finer level of control (disabling individual transformations) can be managed through an addition OptBisect method, but this is not yet used. The skip checking in this implementation is based on (and replaces) the skipOptnoneFunction check. Where that check was being called, a new call has been inserted in its place which checks the bisect limit and the optnone attribute. A new function call has been added for module and SCC passes that behaves in a similar way. Differential Revision: http://reviews.llvm.org/D19172 llvm-svn: 267022
* Typo.Chad Rosier2016-04-201-1/+1
| | | | llvm-svn: 266905
* NFC: make AtomicOrdering an enum classJF Bastien2016-04-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In the context of http://wg21.link/lwg2445 C++ uses the concept of 'stronger' ordering but doesn't define it properly. This should be fixed in C++17 barring a small question that's still open. The code currently plays fast and loose with the AtomicOrdering enum. Using an enum class is one step towards tightening things. I later also want to tighten related enums, such as clang's AtomicOrderingKind (which should be shared with LLVM as a 'C++ ABI' enum). This change touches a few lines of code which can be improved later, I'd like to keep it as NFC for now as it's already quite complex. I have related changes for clang. As a follow-up I'll add: bool operator<(AtomicOrdering, AtomicOrdering) = delete; bool operator>(AtomicOrdering, AtomicOrdering) = delete; bool operator<=(AtomicOrdering, AtomicOrdering) = delete; bool operator>=(AtomicOrdering, AtomicOrdering) = delete; This is separate so that clang and LLVM changes don't need to be in sync. Reviewers: jyknight, reames Subscribers: jyknight, llvm-commits Differential Revision: http://reviews.llvm.org/D18775 llvm-svn: 265602
* [PM] Make the AnalysisManager parameter to run methods a reference.Chandler Carruth2016-03-111-5/+5
| | | | | | | | | | | | This was originally a pointer to support pass managers which didn't use AnalysisManagers. However, that doesn't realistically come up much and the complexity of supporting it doesn't really make sense. In fact, *many* parts of the pass manager were just assuming the pointer was never null already. This at least makes it much more explicit and clear. llvm-svn: 263219
* Minor code cleanup. NFC.Junmo Park2016-02-181-1/+1
| | | | llvm-svn: 261200
* [EarlyCSE] DSE of atomic unordered storesPhilip Reames2015-12-171-18/+17
| | | | | | | | | | The rules for removing trivially dead stores are a lot less complicated than loads. Since we know the later store post dominates the former and the former dominates the later, unless the former has side effects other than the actual store, we can remove it. One slightly surprising thing is that we can freely remove atomic stores, even if the later one isn't atomic. There's no guarantee the atomic one was every visible. For the moment, we don't handle DSE of ordered atomic stores. We could extend the same chain of reasoning to them, but the catch is we'd then have to model the ordering effect without a store instruction. Since our fences are a stronger than our operation orderings, simple using a fence isn't an obvious win. This arguable calls for a refinement in our fence specification, but that's (much) later work. Differential Revision: http://reviews.llvm.org/D15352 llvm-svn: 255914
* [EarlyCSE] DSE of stores which write back loaded valuesPhilip Reames2015-12-161-0/+27
| | | | | | | | | | Extend EarlyCSE with an additional style of dead store elimination. If we write back a value just read from that memory location, we can eliminate the store under the assumption that the value hasn't changed. I'm implementing this mostly because I noticed the omission when looking at the code. It seemed strange to have InstCombine have a peephole which was more powerful than EarlyCSE. :) Differential Revision: http://reviews.llvm.org/D15397 llvm-svn: 255739
* EarlyCSE: fix typo from rL255054.JF Bastien2015-12-091-1/+1
| | | | llvm-svn: 255102
* [EarlyCSE] Value forwarding for unordered atomicsPhilip Reames2015-12-081-19/+77
| | | | | | | | | | | | This patch teaches the fully redundant load part of EarlyCSE how to forward from atomic and volatile loads and stores, and how to eliminate unordered atomics (only). This patch does not include dead store elimination support for unordered atomics, that will follow in the near future. The basic idea is that we allow all loads and stores to be tracked by the AvailableLoad table. We store a bit in the table which tracks whether load/store was atomic, and then only replace atomic loads with ones which were also atomic. No attempt is made to refine our handling of ordered loads or stores. Those are still treated as full fences. We could pretty easily extend the release fence handling to release stores, but that should be a separate patch. Differential Revision: http://reviews.llvm.org/D15337 llvm-svn: 255054
* Reapply 254950 w/fixPhilip Reames2015-12-071-44/+51
| | | | | | | | | | | | | | | | | 254950 ended up being not NFC. The previous code was overriding the flags for whether an instruction read or wrote memory using the target specific flags returned via TTI. I'd missed this in my refactoring. Since I mistakenly built only x86 and didn't notice the number of unsupported tests, I didn't catch that before the original checkin. This raises an interesting issue though. Given we have function attributes (i.e. readonly, readnone, argmemonly) which describe the aliasing of intrinsics, why does TTI have this information overriding the instruction definition at all? I see no reason for this, but decided to preserve existing behavior for the moment. The root issue might be that we don't have a "writeonly" attribute. Original commit message: [EarlyCSE] Simplify and invert ParseMemoryInst [NFCI] Restructure ParseMemoryInst - which was introduced to abstract over target specific load and stores instructions - to just query the underlying instructions. In theory, this could be slightly slower than caching the results, but in practice, it's very unlikely to be measurable. The simple query scheme makes it far easier to understand, and much easier to extend with new queries. Given I'm about to need to add new query types, doing the cleanup first seemed worthwhile. Do we still believe the target specific intrinsic handling is worthwhile in EarlyCSE? It adds quite a bit of complexity and makes the code harder to read. Being able to delete the abstraction entirely would be wonderful. llvm-svn: 254957
* Revert 254950Philip Reames2015-12-071-45/+44
| | | | | | It's causing test failures on AArch64. Due to a bad build config on my part, I apparently wasn't running the tests I thought I was. llvm-svn: 254954
* [EarlyCSE] Simplify and invert ParseMemoryInst [NFCI]Philip Reames2015-12-071-44/+45
| | | | | | | | | | Restructure ParseMemoryInst - which was introduced to abstract over target specific load and stores instructions - to just query the underlying instructions. In theory, this could be slightly slower than caching the results, but in practice, it's very unlikely to be measurable. The simple query scheme makes it far easier to understand, and much easier to extend with new queries. Given I'm about to need to add new query types, doing the cleanup first seemed worthwhile. Do we still believe the target specific intrinsic handling is worthwhile in EarlyCSE? It adds quite a bit of complexity and makes the code harder to read. Being able to delete the abstraction entirely would be wonderful. llvm-svn: 254950
* [EarlyCSE] IsSimple vs IsVolatile naming clarification (NFC)Philip Reames2015-12-051-11/+11
| | | | | | | | | | | | When the notion of target specific memory intrinsics was introduced to EarlyCSE, the commit confused the notions of volatile and simple memory access. Since I'm about to start working on this area, cleanup the naming so that patches aren't horribly confusing. Note that the actual implementation was always bailing if the load or store wasn't simple. Reminder: - "volatile" - C++ volatile, can't remove any memory operations, but in principal unordered - "ordered" - imposes ordering constraints on other nearby memory operations - "atomic" - can't be split or sheared. In LLVM terms, all "ordered" operations are also atomic so the predicate "isAtomic" is often used. - "simple" - a load which is none of the above. These are normal loads and what most of the optimizer works with. llvm-svn: 254805
* [ScalarOpts] Remove dead code.Benjamin Kramer2015-10-151-7/+5
| | | | | | Does not touch debug dumpers. NFC. llvm-svn: 250417
* Scalar: Remove some implicit ilist iterator conversions, NFCDuncan P. N. Exon Smith2015-10-131-1/+1
| | | | | | | Remove some of the implicit ilist iterator conversions in LLVMScalarOpts. More to go. llvm-svn: 250197
* [EarlyCSE] Address post commit review for r249523.Arnaud A. de Grandmaison2015-10-091-10/+10
| | | | llvm-svn: 249814
* [EarlyCSE] Fix handling of target memory intrinsics for CSE'ing loads.Arnaud A. de Grandmaison2015-10-071-14/+23
| | | | | | | | | | | | | | | | | Summary: Some target intrinsics can access multiple elements, using the pointer as a base address (e.g. AArch64 ld4). When trying to CSE such instructions, it must be checked the available value comes from a compatible instruction because the pointer is not enough to discriminate whether the value is correct. Reviewers: ssijaric Subscribers: mcrosier, llvm-commits, aemerson Differential Revision: http://reviews.llvm.org/D13475 llvm-svn: 249523
* [EarlyCSE] Constify ParseMemoryInst methods (NFC).Arnaud A. de Grandmaison2015-10-061-9/+9
| | | | llvm-svn: 249400
OpenPOWER on IntegriCloud