summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Scalar
Commit message (Collapse)AuthorAgeFilesLines
...
* [LoopInstSimplify] Move MemorySSA verification under flag.Alina Sbirlea2019-11-211-1/+2
| | | | | | The verification inside loop passes should be done under the VerifyMemorySSA flag (enabled by EXPESIVE_CHECKS or explicitly with opt), in order to not add to compile time during regular builds.
* [LoopPred] Robustly handle partially unswitched loopsPhilip Reames2019-11-211-0/+29
| | | | We may end up with a case where we have a widenable branch above the loop, but not all widenable branches within the loop have been removed. Since a widenable branch inhibit SCEVs ability to reason about exit counts (by design), we have a tradeoff between effectiveness of this optimization and allowing future widening of the branches within the loop. LoopPred is thought to be one of the most important optimizations for range check elimination, so let's pay the cost.
* Clang-trunk Generates Wrong Debug values with -O1Vedant Kumar2019-11-211-1/+1
| | | | | | | | | | | | | Bit-Tracking Dead Code Elimination (bdce) do not mark dbg.value as undef after deleting instruction. which shows invalid state of variable in debugger. This patches fixes this by marking the dbg.value as undef which depends on dead instruction. This fixes https://bugs.llvm.org/show_bug.cgi?id=41925 Patch by kamlesh kumar! Differential Revision: https://reviews.llvm.org/D70040
* [JumpThreading] Refactor ThreadEdgeKazu Hirata2019-11-211-9/+20
| | | | | | | | | | | | | | | | | | Summary: This patch moves various checks from ThreadEdge to new function TryThreadEdge The rational behind this is that I'd like to use ThreadEdge without its checks in my upcoming patch. This patch preserves lightweight checks as assertions in ThreadEdge. ThreadEdge does not repeat the cost check, however. Reviewers: wmi Subscribers: hiraditya, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70338
* [cmake] Explicitly mark libraries defined in lib/ as "Component Libraries"Tom Stellard2019-11-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Most libraries are defined in the lib/ directory but there are also a few libraries defined in tools/ e.g. libLLVM, libLTO. I'm defining "Component Libraries" as libraries defined in lib/ that may be included in libLLVM.so. Explicitly marking the libraries in lib/ as component libraries allows us to remove some fragile checks that attempt to differentiate between lib/ libraries and tools/ libraires: 1. In tools/llvm-shlib, because llvm_map_components_to_libnames(LIB_NAMES "all") returned a list of all libraries defined in the whole project, there was custom code needed to filter out libraries defined in tools/, none of which should be included in libLLVM.so. This code assumed that any library defined as static was from lib/ and everything else should be excluded. With this change, llvm_map_components_to_libnames(LIB_NAMES, "all") only returns libraries that have been added to the LLVM_COMPONENT_LIBS global cmake property, so this custom filtering logic can be removed. Doing this also fixes the build with BUILD_SHARED_LIBS=ON and LLVM_BUILD_LLVM_DYLIB=ON. 2. There was some code in llvm_add_library that assumed that libraries defined in lib/ would not have LLVM_LINK_COMPONENTS or ARG_LINK_COMPONENTS set. This is only true because libraries defined lib lib/ use LLVMBuild.txt and don't set these values. This code has been fixed now to check if the library has been explicitly marked as a component library, which should now make it easier to remove LLVMBuild at some point in the future. I have tested this patch on Windows, MacOS and Linux with release builds and the following combinations of CMake options: - "" (No options) - -DLLVM_BUILD_LLVM_DYLIB=ON - -DLLVM_LINK_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_BUILD_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_LINK_LLVM_DYLIB=ON Reviewers: beanz, smeenai, compnerd, phosek Reviewed By: beanz Subscribers: wuzish, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, mgorny, mehdi_amini, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, dang, Jim, lenary, s.egerton, pzheng, sameer.abuasal, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70179
* Broaden the definition of a "widenable branch"Philip Reames2019-11-211-5/+6
| | | | | | | | | | | | As a reminder, a "widenable branch" is the pattern "br i1 (and i1 X, WC()), label %taken, label %untaken" where "WC" is the widenable condition intrinsics. The semantics of such a branch (derived from the semantics of WC) is that a new condition can be added into the condition arbitrarily without violating legality. Broaden the definition in two ways: Allow swapped operands to the br (and X, WC()) form Allow widenable branch w/trivial condition (i.e. true) which takes form of br i1 WC() The former is just general robustness (e.g. for X = non-instruction this is what instcombine produces). The later is specifically important as partial unswitching of a widenable range check produces exactly this form above the loop. Differential Revision: https://reviews.llvm.org/D70502
* D'oh. Fix assert after a84922916e6eddf701b39fbd7fe0222cb0fee1d6.James Y Knight2019-11-201-2/+3
| | | | (Which was attempting to fix unused variable warning in NDEBUG mode after 8ba56f322abf848cec78ff7f814f3ad84cd778be)
* Fix unused variable warning in NDEBUG mode after ↵James Y Knight2019-11-201-2/+2
| | | | 8ba56f322abf848cec78ff7f814f3ad84cd778be
* [MemorySSA] Moving at the end often means before terminator.Alina Sbirlea2019-11-203-3/+8
| | | | | | | | | | | | | Moving accesses in MemorySSA at InsertionPlace::End, when an instruction is moved into a block, almost always means insert at the end of the block, but before the block terminator. This matters when the block terminator is a MemoryAccess itself (an invoke), and the insertion must be done before the terminator for the update to be correct. Insert an additional position: InsertionPlace:BeforeTerminator and update current usages where this applies. Resolves PR44027.
* [MemorySSA] Update analysis when the terminator is a memory instruction.Alina Sbirlea2019-11-201-0/+3
| | | | | Update MemorySSA when moving the terminator instruction, as that may be a memory touching instruction. Resolves PR44029.
* Move widenable branch formation into makeGuardControlFlowExplicit helperPhilip Reames2019-11-202-16/+3
| | | | This is mostly NFC, but I removed the setting of the guard's calling convention onto the WC call. Why? Because it was untested, and was producing an ill defined output as the declaration's convention wasn't been changed leaving a mismatch which is UB.
* [GuardWidening] Remove WidenFrequentBranches transformPhilip Reames2019-11-191-68/+6
| | | | This code has never been enabled. While it is tested, it's complicating some refactoring. If we decide to re-implement this, doing it in SimplifyCFG would probably make more sense anyways.
* [NFC] Factor out utilities for manipulating widenable branchesPhilip Reames2019-11-192-13/+4
| | | | | | With the widenable condition construct, we have the ability to reason about branches which can be 'widened' (i.e. made to fail more often). We've got a couple o transforms which leverage this. This patch just cleans up the API a bit. This is prep work for generalizing our definition of a widenable branch slightly. At the moment "br i1 (and A, wc()), ..." is considered widenable, but oddly, neither "br i1 (and wc(), B), ..." or "br i1 wc(), ..." is. That clearly needs addressed, so first, let's centralize the code in one place.
* [LoopPred] Generalize profitability check to handle unswitch outputPhilip Reames2019-11-191-1/+12
| | | | Unswitch (and other loop transforms) like to generate loop exit blocks with unconditional successors, and phi nodes (LCSSA, or simple multiple exiting blocks sharing an exit). Generalize the "likely very rare exit" check slightly to handle this form.
* [LoopPred/WC] Use a dominating widenable condition to remove analyze loop exitsPhilip Reames2019-11-181-9/+206
| | | | | | | | | | | | This implements a version of the predicateLoopExits transform from IndVarSimplify extended to exploit widenable conditions - and thus be much wider in scope of legality. The code structure ends up being almost entirely different, so I chose to duplicate this into the LoopPredication pass instead of trying to reuse the code in the IndVars. The core notions of the transform are as follows: If we have a widenable condition which controls entry into the loop, we're allowed to widen it arbitrarily. Given that, it's simply a *profitability* question as to what conditions to fold into the widenable branch. To avoid pass ordering issues, we want to avoid widening cases that would otherwise be dischargeable. Or... widen in a form which can still be discharged. Thus, we phrase the transform as selecting one analyzeable exit from the set of analyzeable exits to keep. This avoids creating pass ordering complexities. Since none of the above proves that we actually exit through our analyzeable exits - we might exit through something else entirely - we limit ourselves to cases where a) the latch is analyzeable and b) the latch is predicted taken, and c) the exit being removed is statically cold. Differential Revision: https://reviews.llvm.org/D69830
* Remove Support/Options.h, it is unusedReid Kleckner2019-11-151-1/+1
| | | | | | | | | | | | | | | | | It was added in 2014 in 732e0aa9fb84f1 with one use in Scalarizer.cpp. That one use was then removed when porting to the new pass manager in 2018 in b6f76002d9158628e78. While the RFC and the desire to get off of static initializers for cl::opt all still stand, this code is now dead, and I think we should delete this code until someone is ready to do the migration. There were many clients of CommandLine.h that were it transitively through LLVMContext.h, so I cleaned that up in 4c1a1d3cf97e1ede466. Reviewers: beanz Differential Revision: https://reviews.llvm.org/D70280
* [Scalarizer] Treat values from unreachable blocks as undefMikael Holmen2019-11-151-5/+27
| | | | | | | | | | | | | | | | | | | | | | | | Summary: When scalarizing PHI nodes we might try to examine/rewrite InsertElement nodes in predecessors. If those predecessors are unreachable from entry, then the IR in those blocks could have unexpected properties resulting in infinite loops in Scatterer::operator[]. By simply treating values originating from instructions in unreachable blocks as undef we do not need to analyse them further. This fixes PR41723. Reviewers: bjope Reviewed By: bjope Subscribers: bjope, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70171
* Add missing includes needed to prune LLVMContext.h include, NFCReid Kleckner2019-11-149-0/+9
| | | | | These are a pre-requisite to removing #include "llvm/Support/Options.h" from LLVMContext.h: https://reviews.llvm.org/D70280
* Fix uninitialized variable warning. NFCI.Simon Pilgrim2019-11-141-2/+2
|
* SROA - fix uninitialized variable warnings. NFCI.Simon Pilgrim2019-11-141-5/+5
|
* Sink all InitializePasses.h includesReid Kleckner2019-11-1368-26/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This file lists every pass in LLVM, and is included by Pass.h, which is very popular. Every time we add, remove, or rename a pass in LLVM, it caused lots of recompilation. I found this fact by looking at this table, which is sorted by the number of times a file was changed over the last 100,000 git commits multiplied by the number of object files that depend on it in the current checkout: recompiles touches affected_files header 342380 95 3604 llvm/include/llvm/ADT/STLExtras.h 314730 234 1345 llvm/include/llvm/InitializePasses.h 307036 118 2602 llvm/include/llvm/ADT/APInt.h 213049 59 3611 llvm/include/llvm/Support/MathExtras.h 170422 47 3626 llvm/include/llvm/Support/Compiler.h 162225 45 3605 llvm/include/llvm/ADT/Optional.h 158319 63 2513 llvm/include/llvm/ADT/Triple.h 140322 39 3598 llvm/include/llvm/ADT/StringRef.h 137647 59 2333 llvm/include/llvm/Support/Error.h 131619 73 1803 llvm/include/llvm/Support/FileSystem.h Before this change, touching InitializePasses.h would cause 1345 files to recompile. After this change, touching it only causes 550 compiles in an incremental rebuild. Reviewers: bkramer, asbirlea, bollu, jdoerfert Differential Revision: https://reviews.llvm.org/D70211
* [GVNHoist] Preserve AAResults.Alina Sbirlea2019-11-121-0/+1
| | | | Resolves PR38906, PR40898.
* [DBG][OPT] Attempt to salvage or undef debug info when removing trivially ↵Tom Weaver2019-11-121-0/+2
| | | | | | | | deletable instructions in the Reassociate Expression pass. Reviewed By: aprantl, vsk Differential revision: https://reviews.llvm.org/D69943
* [LoopInterchange] Only skip PHIs with incoming values from the inner loop.Florian Hahn2019-11-121-7/+7
| | | | | | | | | | | | | | Currently we have limited support for outer loops with multiple basic blocks after the inner loop exit. But the current checks for creating PHIs for loop exit values only assumes the header and latches of the outer loop. It is better to just skip incoming values defined in the original inner loops. Those are handled earlier. Reviewers: efriedma, mcrosier Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D70059
* Revert "[DBG][OPT] Attempt to salvage or undef debug info when removing ↵Tom Weaver2019-11-111-2506/+0
| | | | | | trivially deletable instructions in the Reassociate Expression pass." This reverts commit 1984a27db58e9053371ab6d6dc288c81c8a071ac.
* [DBG][OPT] Attempt to salvage or undef debug info when removing trivially ↵Tom Weaver2019-11-111-0/+2506
| | | | | | | | deletable instructions in the Reassociate Expression pass. Reviewed By: aprantl, vsk Differential revision: https://reviews.llvm.org/D69943
* [NFC][TEST_COMMIT] Add fullstop to comment.Tom Weaver2019-11-111-1/+1
|
* [JumpThreading] Fix a comment typo (NFC)Kazu Hirata2019-11-081-1/+1
| | | | | | | | | | Reviewers: kazu Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70013
* [LICM] Support hosting of dynamic allocas out of loopsPhilip Reames2019-11-081-0/+45
| | | | | | | | | | | | This patch implements a correct, but not terribly useful, transform. In particular, if we have a dynamic alloca in a loop which is guaranteed to execute, and provably not captured, we hoist the alloca out of the loop. The capture tracking is needed so that we can prove that each previous stack region dies before the next one is allocated. The transform decreases the amount of stack allocation needed by a linear factor (e.g. the iteration count of the loop). Now, I really hope no one is actually using dynamic allocas. As such, why this patch? Well, the actual problem I'm hoping to make progress on is allocation hoisting. There's a large draft patch out for review (https://reviews.llvm.org/D60056), and this patch was the smallest chunk of testable functionality I could come up with which takes a step vaguely in that direction. Once this is in, it makes motivating the changes to capture tracking mentioned in TODOs testable. After that, I hope to extend this to trivial malloc free regions (i.e. free dominating all loop exits) and allocation functions for GCed languages. Differential Revision: https://reviews.llvm.org/D69227
* [LICM] Hoisting of widenable conditions out of loopsPhilip Reames2019-11-081-0/+4
| | | | | | The change itself is straight forward and obvious, but ... there's an existing test checking for exactly the opposite. Both I and Artur think this is simply conservatism in the initial implementation. If anyone bisects a problem to this, a counter example will be very interesting. Differential Revision: https://reviews.llvm.org/D69907
* [NFC][IndVarS] Adjust a commentDaniil Suchkov2019-11-081-1/+1
| | | | (test commit)
* [LoopPred] Enable new transformation by defaultPhilip Reames2019-11-061-1/+1
| | | | | | | | The basic idea of the transform is to convert variant loop exit conditions into invariant exit conditions by changing the iteration on which the exit is taken when we know that the trip count is unobservable. See the original patch which introduced the code for a more complete explanation. The individual parts of this have been reviewed, the result has been fuzzed, and then further analyzed by hand, but despite all of that, I will not be suprised to see breakage here. If you see problems, please don't hesitate to revert - though please do provide a test case. The most likely class of issues are latent SCEV bugs and without a reduced test case, I'll be essentially stuck on reducing them. (Note: A bunch of tests were opted out of the new transform to preserve coverage. That landed in a previous commit to simplify revert cycles if they turn out to be needed.)
* [JumpThreading] Factor out code to clone instructions (NFC)Kazu Hirata2019-11-061-31/+45
| | | | | | | | | | | | | | Summary: This patch factors out code to clone instructions -- partly for readability and partly to facilitate an upcoming patch of my own. Reviewers: wmi Subscribers: hiraditya, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69861
* [WC] Fix a subtle bug in our definition of widenable branchPhilip Reames2019-11-062-7/+8
| | | | | | | | | | | | We had a subtle, but nasty bug in our definition of a widenable branch, and thus in the transforms which used that utility. Specifically, we returned true for any branch which included a widenable condition within it's condition, regardless of whether that widenable condition also had other uses. The problem is that the result of the WC() call is defined to be one particular value. As such, all users must agree as to what that value is. If we widen a branch without also updating *all other users* of the WC in the same way, we have broken the required semantics. Most of the textual diff is updating existing transforms not to leave dead uses hanging around. They're largely NFC as the dead instructions would be immediately deleted by other passes. The reason to make these changes is so that the transforms preserve the widenable branch form. In practice, we don't get bitten by this only because it isn't profitable to CSE WC() calls and the lowering pass from guards uses distinct WC calls per branch. Differential Revision: https://reviews.llvm.org/D69916
* [LoopPred] Fix two subtle issues found by inspectionPhilip Reames2019-11-061-8/+26
| | | | | | | | | | | | This patch fixes two issues noticed by inspection when going to enable the loop predication code in IndVarSimplify. Issue 1 - Both the LoopPredication transform, and the already on by default optimizeLoopExits transform, modify the exit count of the exits they modify. (either to 0 or Infinity) Looking at the code more closely, this was not reflected into SCEV and we were instead running later transforms with incorrect SCEVs. Fixing this requires forgetting the loop, weakening a too strong assert, and updating SCEV to not pessimize results when a loop is provable untaken. I haven't been able to find a test case to demonstrate the miscompile. Issue 2 - For modules without a data layout, we can end up with unsized pointer typed exit counts. Just bail out of this case. I think these are the last two issues which need addressed before we enable this by default. The code has already survived a decent amount of fuzzing without revealing either of the above. Differential Revision: https://reviews.llvm.org/D69695
* [JumpThreading] Factor out code to merge basic blocks (NFC)Kazu Hirata2019-11-051-43/+52
| | | | | | | | | | | | | | | Summary: This patch factors out code to merge a basic block with its sole successor -- partly for readability and partly to facilitate an upcoming patch of my own. Reviewers: wmi Subscribers: hiraditya, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69852
* [JumpThreading] Factor out common code to update the SSA form (NFC)Kazu Hirata2019-11-051-75/+46
| | | | | | | | | | | | | | | Summary: This patch factors out common code to update the SSA form in JumpThreading.cpp -- partly for readability and partly to facilitate an coming patch of my own. Reviewers: wmi Subscribers: hiraditya, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69811
* [GVN] Fix uninitialized variable warnings. NFCI.Simon Pilgrim2019-11-052-12/+12
|
* Add missing GVN =operator. NFCI.Simon Pilgrim2019-11-051-0/+1
| | | | Fixes PVS Studio warning that the 'ValueTable' class implements a copy constructor, but lacks the '=' operator.
* Revert BCmp Loop Idiom recognition transform (PR43870)Roman Lebedev2019-11-021-877/+8
| | | | | | | | | | | | | | | | | As discussed in https://bugs.llvm.org/show_bug.cgi?id=43870, this transform is missing a crucial legality check: the old (non-countable) loop would early-return upon first mismatch, but there is no such guarantee for bcmp/memcmp. We'd need to ensure that [PtrA, PtrA+NBytes) and [PtrB, PtrB+NBytes) are fully dereferenceable memory regions. But that would limit the transform to constant loop trip counts and would further cripple it because dereferenceability analysis is *very* partial. Furthermore, even if all that is done, every single test would need to be rewritten from scratch. So let's just give up.
* [LICM] Invalidate SCEV upon instruction hoistingSerguei Katkov2019-10-311-14/+20
| | | | | | | | | | | Since SCEV can cache information about location of an instruction, it should be invalidated when the instruction is moved. There should be similar bug in code sinking part of LICM, it will be fixed in a follow-up change. Patch Author: Daniil Suchkov Reviewers: asbirlea, mkazantsev, reames Reviewed By: asbirlea Subscribers: hiraditya, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D69370
* [CVP] prevent propagating poison when substituting edge values into a phi ↵Sanjay Patel2019-10-281-1/+8
| | | | | | | | | | | | | | | | | (PR43802) This phi simplification transform was added with: D45448 However as shown in PR43802: https://bugs.llvm.org/show_bug.cgi?id=43802 ...we must be careful not to propagate poison when we do the substitution. There might be some more complicated analysis possible to retain the overflow flag, but it should always be safe and easy to drop flags (we have similar behavior in instcombine and other passes). Differential Revision: https://reviews.llvm.org/D69442
* Use isConvergent helper instead of directly checking attributeMatt Arsenault2019-10-272-2/+2
|
* [Alignment][NFC] Convert AllocaInst to MaybeAlignGuillaume Chatelet2019-10-251-11/+10
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Reviewed By: courbet Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69301
* [SCEV] Expose and use maximum constant exit counts for individual loop exitsPhilip Reames2019-10-241-3/+3
| | | | | | | | We were already going to all of the trouble of computing maximum constant exit counts for each loop exit, we might as well expose them through the API. The change in IndVars is mostly to demonstrate that the wired up code works, but it als very slightly strengthens the transform. The strengthened case is rather narrow though: it requires one exactly analyzeable exit, one imprecisely analyzeable exit (with the upper bound less than the precise one), and one unanalyzeable exit. I coudn't construct a reasonably stable test case. This does increase the memory usage of the BackedgeTakenCount by a factor of 2 in the worst case. I also noticed the loop in IndVars is O(#Exits ^ 2). This doesn't change with this patch. A future patch will cache this result inside of SCEV to avoid requering.
* Test commit access via gitPhilip Reames2019-10-241-1/+0
|
* [Alignment][NFC] Convert StoreInst to MaybeAlignGuillaume Chatelet2019-10-221-2/+3
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: hiraditya, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69303 llvm-svn: 375499
* [Alignment][NFC] Convert LoadInst to MaybeAlignGuillaume Chatelet2019-10-223-6/+7
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: hiraditya, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69302 llvm-svn: 375498
* [CVP] No-wrap deduction for `shl`Roman Lebedev2019-10-211-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the last `OverflowingBinaryOperator` for which we don't deduce flags. D69217 taught `ConstantRange::makeGuaranteedNoWrapRegion()` about it. The effect is better than of the `mul` patch (D69203): | statistic | old | new | delta | % change | | correlated-value-propagation.NumAddNUW | 7145 | 7144 | -1 | -0.0140% | | correlated-value-propagation.NumAddNW | 12126 | 12125 | -1 | -0.0082% | | correlated-value-propagation.NumAnd | 443 | 446 | 3 | 0.6772% | | correlated-value-propagation.NumNSW | 5986 | 7158 | 1172 | 19.5790% | | correlated-value-propagation.NumNUW | 10512 | 13304 | 2792 | 26.5601% | | correlated-value-propagation.NumNW | 16498 | 20462 | 3964 | 24.0272% | | correlated-value-propagation.NumShlNSW | 0 | 1172 | 1172 | | | correlated-value-propagation.NumShlNUW | 0 | 2793 | 2793 | | | correlated-value-propagation.NumShlNW | 0 | 3965 | 3965 | | | instcount.NumAShrInst | 13824 | 13790 | -34 | -0.2459% | | instcount.NumAddInst | 277584 | 277586 | 2 | 0.0007% | | instcount.NumAndInst | 66061 | 66056 | -5 | -0.0076% | | instcount.NumBrInst | 709153 | 709147 | -6 | -0.0008% | | instcount.NumICmpInst | 483709 | 483708 | -1 | -0.0002% | | instcount.NumSExtInst | 79497 | 79496 | -1 | -0.0013% | | instcount.NumShlInst | 40691 | 40654 | -37 | -0.0909% | | instcount.NumSubInst | 61997 | 61996 | -1 | -0.0016% | | instcount.NumZExtInst | 68208 | 68211 | 3 | 0.0044% | | instcount.TotalBlocks | 843916 | 843910 | -6 | -0.0007% | | instcount.TotalInsts | 7387528 | 7387448 | -80 | -0.0011% | Reviewers: nikic, reames, sanjoy, timshen Reviewed By: nikic Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69277 llvm-svn: 375455
* GVNHoist - silence static analyzer dyn_cast<> null dereference warning in ↵Simon Pilgrim2019-10-211-1/+1
| | | | | | | | hasEHOrLoadsOnPath call. NFCI. The static analyzer is warning about a potential null dereference, but we should be able to use cast<> directly and if not assert will fire for us. llvm-svn: 375429
OpenPOWER on IntegriCloud