summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms/LICM
Commit message (Collapse)AuthorAgeFilesLines
* Revert "[LICM] Support hosting of dynamic allocas out of loops"Philip Reames2020-02-261-168/+0
| | | | | | | | This reverts commit 8d22100f66c4170510c6ff028c60672acfe1cff9. There was a functional regression reported (https://bugs.llvm.org/show_bug.cgi?id=44996). I'm not actually sure the patch is wrong, but I don't have time to investigate currently, and this line of work isn't something I'm likely to get back to quickly. (cherry picked from commit 14845b2c459021e3dbf2ead52d707d4a7db40cbb)
* Filter callbr insts from critical edge splittingBill Wendling2020-02-211-0/+18
| | | | | | | | Similarly to how splitting predecessors with an indirectbr isn't handled in the generic way, we also shouldn't split callbrs, for similar reasons. (cherry picked from commit 2fe457690da0fc38bc7f9f1d0aee2ba6a6a16ada)
* Migrate function attribute "no-frame-pointer-elim" to "frame-pointer"="all" ↵Fangrui Song2019-12-241-1/+1
| | | | as cleanups after D56351
* [ValueTracking] Allow context-sensitive nullness check for non-pointersJohannes Doerfert2019-12-091-3/+1
| | | | | | | | | | | | | | | | | | Summary: Same as D60846 and D69571 but with a fix for the problem encountered after them. Both times it was a missing context adjustment in the handling of PHI nodes. The reproducers created from the bugs that caused the old commits to be reverted are included. Reviewers: nikic, nlopes, mkazantsev, spatel, dlrobertson, uabelho, hakzsam, hans Subscribers: hiraditya, bollu, asbirlea, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71181
* [TTI] Fix cast cost on vector types.Michael Liao2019-11-132-0/+23
| | | | - Only split vector types when both src and dst types are splittable.
* Revert 57dd4b0 "[ValueTracking] Allow context-sensitive nullness check for ↵Hans Wennborg2019-11-131-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | non-pointers" This caused miscompiles of Chromium (https://crbug.com/1023818). The reduced repro is small enough to fit here: $ cat /tmp/a.c unsigned char f(unsigned char *p) { unsigned char result = 0; for (int shift = 0; shift < 1; ++shift) result |= p[0] << (shift * 8); return result; } $ bin/clang -O2 -S -o - /tmp/a.c | grep -A4 f: f: # @f .cfi_startproc # %bb.0: # %entry xorl %eax, %eax retq That's nicely optimized, but I don't think it's the right result :-) > Same as D60846 but with a fix for the problem encountered there which > was a missing context adjustment in the handling of PHI nodes. > > The test that caused D60846 to be reverted was added in e15ab8f277c7. > > Reviewers: nikic, nlopes, mkazantsev,spatel, dlrobertson, uabelho, hakzsam > > Subscribers: hiraditya, bollu, llvm-commits > > Tags: #llvm > > Differential Revision: https://reviews.llvm.org/D69571 This reverts commit 57dd4b03e4806bbb4760ab6150940150d884df20.
* [LICM] Support hosting of dynamic allocas out of loopsPhilip Reames2019-11-081-0/+168
| | | | | | | | | | | | 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-7/+42
| | | | | | 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
* [ValueTracking] Allow context-sensitive nullness check for non-pointersJohannes Doerfert2019-10-311-3/+1
| | | | | | | | | | | | | | | Same as D60846 but with a fix for the problem encountered there which was a missing context adjustment in the handling of PHI nodes. The test that caused D60846 to be reverted was added in e15ab8f277c7. Reviewers: nikic, nlopes, mkazantsev,spatel, dlrobertson, uabelho, hakzsam Subscribers: hiraditya, bollu, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69571
* [MemorySSA] Don't hoist stores if interfering uses (as calls) exist.Alina Sbirlea2019-10-031-1/+1
| | | | llvm-svn: 373674
* Revert "[LoopInfo] Limit the iterations to check whether a loop has dedicatedWei Mi2019-09-271-102/+0
| | | | | | | | | | | exits" Get a better approach in https://reviews.llvm.org/D68107 to solve the problem. Revert the initial patch and will commit the new one soon. This reverts commit rL372990. llvm-svn: 373044
* [LoopInfo] Limit the iterations to check whether a loop has dedicated exitsWei Mi2019-09-261-0/+102
| | | | | | | | | | | | | | for extreme large case. We had a case that a single loop which has 4000 exits and the average number of predecessors of each exit is > 1000, and we found compiling the case spent a significant amount of time on checking whether a loop has dedicated exits. This patch adds a limit for the iterations to the check. With the patch, the time to compile our testcase reduced from 1000s to 200s (clang release build). Differential Revision: https://reviews.llvm.org/D67359 llvm-svn: 372990
* [LICM/AST] Check if the AliasAny set is removed from the tracker.Alina Sbirlea2019-09-121-0/+27
| | | | | | | | | | | | | | | | Summary: Resolves PR38513. Credit to @bjope for debugging this. Reviewers: hfinkel, uabelho, bjope Subscribers: sanjoy.google, bjope, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67417 llvm-svn: 371752
* Cleanup test.Alina Sbirlea2019-09-061-2/+1
| | | | llvm-svn: 371158
* [AliasSetTracker] Correct AAInfo check.Alina Sbirlea2019-09-051-0/+71
| | | | | | | | Properly check if NewAAInfo conflicts with AAInfo. Update local variable and alias set that a change occured when a conflict is found. Resolves PR42969. llvm-svn: 371139
* [LoopPassManager + MemorySSA] Only enable use of MemorySSA for LPMs known to ↵Alina Sbirlea2019-08-218-16/+57
| | | | | | | | | | | | | | | | | | | | | | | | preserve it. Summary: Add a flag to the FunctionToLoopAdaptor that allows enabling MemorySSA only for the loop pass managers that are known to preserve it. If an LPM is known to have only loop transforms that *all* preserve MemorySSA, then use MemorySSA if `EnableMSSALoopDependency` is set. If an LPM has loop passes that do not preserve MemorySSA, then the flag passed is `false`, regardless of the value of `EnableMSSALoopDependency`. When using a custom loop pass pipeline via `passes=...`, use keyword `loop` vs `loop-mssa` to use MemorySSA in that LPM. If a loop that does not preserve MemorySSA is added while using the `loop-mssa` keyword, that's an error. Add the new `loop-mssa` keyword to a few tests where a difference occurs when enabling MemorySSA. Reviewers: chandlerc Subscribers: mehdi_amini, Prazek, george.burgess.iv, sanjoy.google, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66376 llvm-svn: 369548
* Revert '[LICM] Make Loop ICM profile aware' and 'Fix pass dependency for LICM'David L. Jones2019-08-141-8/+2
| | | | | | | This reverts r368526 (git commit 7e71aa24bc0788690fea7f0d7eab400c6a784deb) This reverts r368542 (git commit cb5a90fd314a7914cf293797bb4fd7a6841052cf) llvm-svn: 368800
* [LICM] Make Loop ICM profile awareWenlei He2019-08-111-2/+8
| | | | | | | | | | | | | | | | | | | | | Summary: Hoisting/sinking instruction out of a loop isn't always beneficial. Hoisting an instruction from a cold block inside a loop body out of the loop could hurt performance. This change makes Loop ICM profile aware - it now checks block frequency to make sure hoisting/sinking anly moves instruction to colder block. Test Plan: ninja check Reviewers: asbirlea, sanjoy, reames, nikic, hfinkel, vsk Reviewed By: asbirlea Subscribers: fhahn, vsk, davidxl, xbolva00, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65060 llvm-svn: 368526
* [LICM] Support unary FNeg in LICMCameron McInally2019-08-081-2/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D65908 llvm-svn: 368350
* Add llvm.licm.disable metadataTim Corringham2019-08-081-0/+33
| | | | | | | | | | | | | | For some targets the LICM pass can result in sub-optimal code in some cases where it would be better not to run the pass, but it isn't always possible to suppress the transformations heuristically. Where the front-end has insight into such cases it is beneficial to attach loop metadata to disable the pass - this change adds the llvm.licm.disable metadata to enable that. Differential Revision: https://reviews.llvm.org/D64557 llvm-svn: 368296
* [NFC][LICM] Pre-commit test for unary FNeg support in LICM.Cameron McInally2019-08-071-0/+23
| | | | llvm-svn: 368211
* IR: print value numbers for unnamed function argumentsTim Northover2019-08-031-2/+2
| | | | | | | | | | For consistency with normal instructions and clarity when reading IR, it's best to print the %0, %1, ... names of function arguments in definitions. Also modifies the parser to accept IR in that form for obvious reasons. llvm-svn: 367755
* Add, and infer, a nofree function attributeBrian Homerding2019-07-081-1/+1
| | | | | | | | | | | | This patch adds a function attribute, nofree, to indicate that a function does not, directly or indirectly, call a memory-deallocation function (e.g., free, C++'s operator delete). Reviewers: jdoerfert Differential Revision: https://reviews.llvm.org/D49165 llvm-svn: 365336
* [LICM & MSSA] Limit unsafe sinking and hoisting.Alina Sbirlea2019-06-201-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The getClobberingMemoryAccess API checks for clobbering accesses in a loop by walking the backedge. This may check if a memory access is being clobbered by the loop in a previous iteration, depending how smart AA got over the course of the updates in MemorySSA (it does not occur when built from scratch). If no clobbering access is found inside the loop, it will optimize to an access outside the loop. This however does not mean that access is safe to sink. Given: ``` for i load a[i] store a[i] ``` The access corresponding to the load can be optimized to outside the loop, and the load can be hoisted. But it is incorrect to sink it. In order to sink the load, we'd need to check no Def clobbers the Use in the same iteration. With this patch we currently restrict sinking to either Defs not existing in the loop, or Defs preceding the load in the same block. An easy extension is to ensure the load (Use) post-dominates all Defs. Caught by PR42294. This issue also shed light on the converse problem: hoisting stores in this same scenario would be illegal. With this patch we restrict hoisting of stores to the case when their corresponding Defs are dominating all Uses in the loop. Reviewers: george.burgess.iv Subscribers: jlebar, Prazek, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63582 llvm-svn: 363982
* [LICM] Allow AliasSetMap to contain top-level loops.Florian Hahn2019-05-141-0/+46
| | | | | | | | | | | | | | | When an outer loop gets deleted by a different pass, before LICM visits it, we cannot clean up its sub-loops in AliasSetMap, because at the point we receive the deleteAnalysisLoop callback for the outer loop, the loop object is already invalid and we cannot access its sub-loops any longer. Reviewers: asbirlea, sanjoy, chandlerc Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D61904 llvm-svn: 360704
* Revert "[ValueTracking] Improve isKnowNonZero for Ints"Nikita Popov2019-05-081-1/+3
| | | | | | | | | This reverts commit 3b137a495686bd6018d115ea82fb8bb7718349fd. As reported in https://reviews.llvm.org/D60846, this is causing miscompiles. llvm-svn: 360260
* [ValueTracking] Improve isKnowNonZero for IntsDan Robertson2019-05-081-3/+1
| | | | | | | | | Improve isKnownNonZero for integers in order to improve cttz optimizations. Differential Revision: https://reviews.llvm.org/D60846 llvm-svn: 360222
* [LICM] auto-generate complete test checks; NFCSanjay Patel2019-05-031-3/+27
| | | | llvm-svn: 359881
* Revert "Temporarily Revert "Add basic loop fusion pass.""Eric Christopher2019-04-1792-0/+11372
| | | | | | | | The reversion apparently deleted the test/Transforms directory. Will be re-reverting again. llvm-svn: 358552
* Temporarily Revert "Add basic loop fusion pass."Eric Christopher2019-04-1792-11372/+0
| | | | | | | | As it's causing some bot failures (and per request from kbarton). This reverts commit r358543/ab70da07286e618016e78247e4a24fcb84077fda. llvm-svn: 358546
* [LICM & MemorySSA] Don't sink/hoist stores in the presence of ordered loads.Alina Sbirlea2019-03-201-2/+1
| | | | | | | | | | | | | | | | | | | | | Summary: Before this patch, if any Use existed in the loop, with a defining access in the loop, we conservatively decide to not move the store. What this approach was missing, is that ordered loads are not Uses, they're Defs in MemorySSA. So, even when the clobbering walker does not find that volatile load to interfere, we still cannot hoist a store past a volatile load. Resolves PR41140. Reviewers: george.burgess.iv Subscribers: sanjoy, jlebar, Prazek, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59564 llvm-svn: 356588
* [LICM] Infer proper alignment from loads during scalar promotionPhilip Reames2019-03-012-12/+10
| | | | | | | | | | This patch fixes an issue where we would compute an unnecessarily small alignment during scalar promotion when no store is not to be guaranteed to execute, but we've proven load speculation safety. Since speculating a load requires proving the existing alignment is valid at the new location (see Loads.cpp), we can use the alignment fact from the load. For non-atomics, this is a performance problem. For atomics, this is a correctness issue, though an *incredibly* rare one to see in practice. For atomics, we might not be able to lower an improperly aligned load or store (i.e. i32 align 1). If such an instruction makes it all the way to codegen, we *may* fail to codegen the operation, or we may simply generate a slow call to a library function. The part that makes this super hard to see in practice is that the memory location actually *is* well aligned, and instcombine knows that. So, to see a failure, you have to have a) hit the bug in LICM, b) somehow hit a depth limit in InstCombine/ValueTracking to avoid fixing the alignment, and c) then have generated an instruction which fails codegen rather than simply emitting a slow libcall. All around, pretty hard to hit. Differential Revision: https://reviews.llvm.org/D58809 llvm-svn: 355217
* [Tests] Strengthen LICM test corpus to show alignment striping. (part 2)Philip Reames2019-02-281-0/+31
| | | | | | This should have been part of r355110, but my brain isn't quite awake yet, despite the coffee. Per the original submit comment... Doing scalar promotion w/o being able to prove the alignment of the hoisted load or sunk store is a bug. Update tests to actually show the alignment so that impact of the patch which fixes this can be seen. llvm-svn: 355111
* [Tests] Strengthen LICM test corpus to show alignment stripingPhilip Reames2019-02-282-0/+30
| | | | | | Doing scalar promotion w/o being able to prove the alignment of the hoisted load or sunk store is a bug. Update tests to actually show the alignment so that impact of the patch which fixes this can be seen. llvm-svn: 355110
* [TEST] Update test comments, refactor checks with update_test_checks.pyMax Kazantsev2019-02-151-90/+216
| | | | | | | This patch changes messages in guards-related tests to adequately reflect reality. llvm-svn: 354101
* [LICM&MSSA] Limit store hoisting.Alina Sbirlea2019-02-111-4/+38
| | | | | | | | | | | | | | | | | | | Summary: If there is no clobbering access for a store inside the loop, that store can only be hoisted if there are no interfearing loads. A more general verification introduced here: there are no loads that are not optimized to an access outside the loop. Addresses PR40586. Reviewers: george.burgess.iv Subscribers: sanjoy, jlebar, Prazek, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57967 llvm-svn: 353734
* [MemorySSA +LICM CFHoist] Solve PR40317.Alina Sbirlea2019-01-241-0/+62
| | | | | | | | | | | | | | | Summary: MemorySSA needs updating each time an instruction is moved. LICM and control flow hoisting re-hoists instructions, thus needing another update when re-moving those instructions. Pending cleanup: the MSSA update is duplicated, should be moved inside moveInstructionBefore. Reviewers: jnspaulsson Subscribers: sanjoy, jlebar, Prazek, george.burgess.iv, llvm-commits Differential Revision: https://reviews.llvm.org/D57176 llvm-svn: 352092
* Use MemorySSA in LICM to do sinking and hoisting.Alina Sbirlea2019-01-1014-44/+96
| | | | | | | | | | | | | | | | | | Summary: Step 2 in using MemorySSA in LICM: Use MemorySSA in LICM to do sinking and hoisting, all under "EnableMSSALoopDependency" flag. Promotion is disabled. Enable flag in LICM sink/hoist tests to test correctness of this change. Moved one test which relied on promotion, in order to test all sinking tests. Reviewers: sanjoy, davide, gberry, george.burgess.iv Subscribers: llvm-commits, Prazek Differential Revision: https://reviews.llvm.org/D40375 llvm-svn: 350879
* [LICM] Adjust how moving the re-hoist point worksJohn Brawn2019-01-041-0/+164
| | | | | | | | | | | | | | | | In some cases the order that we hoist instructions in means that when rehoisting (which uses the same order as hoisting) we can rehoist to a block A, then a block B, then block A again. This currently causes an assertion failure as it expects that when changing the hoist point it only ever moves to a block that dominates the hoist point being moved from. Fix this by moving the re-hoist point when it doesn't dominate the dominator of hoisted instruction, or in other words when it wouldn't dominate the uses of the instruction being rehoisted. Differential Revision: https://reviews.llvm.org/D55266 llvm-svn: 350408
* Introduce llvm.experimental.widenable_condition intrinsicMax Kazantsev2018-12-071-0/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduces a new instinsic `@llvm.experimental.widenable_condition` that allows explicit representation for guards. It is an alternative to using `@llvm.experimental.guard` intrinsic that does not contain implicit control flow. We keep finding places where `@llvm.experimental.guard` is not supported or treated too conservatively, and there are 2 reasons to that: - `@llvm.experimental.guard` has memory write side effect to model implicit control flow, and this sometimes confuses passes and analyzes that work with memory; - Not all passes and analysis are aware of the semantics of guards. These passes treat them as regular throwing call and have no idea that the condition of guard may be used to prove something. One well-known place which had caused us troubles in the past is explicit loop iteration count calculation in SCEV. Another example is new loop unswitching which is not aware of guards. Whenever a new pass appears, we potentially have this problem there. Rather than go and fix all these places (and commit to keep track of them and add support in future), it seems more reasonable to leverage the existing optimizer's logic as much as possible. The only significant difference between guards and regular explicit branches is that guard's condition can be widened. It means that a guard contains (explicitly or implicitly) a `deopt` block successor, and it is always legal to go there no matter what the guard condition is. The other successor is a guarded block, and it is only legal to go there if the condition is true. This patch introduces a new explicit form of guards alternative to `@llvm.experimental.guard` intrinsic. Now a widenable guard can be represented in the CFG explicitly like this: %widenable_condition = call i1 @llvm.experimental.widenable.condition() %new_condition = and i1 %cond, %widenable_condition br i1 %new_condition, label %guarded, label %deopt guarded: ; Guarded instructions deopt: call type @llvm.experimental.deoptimize(<args...>) [ "deopt"(<deopt_args...>) ] The new intrinsic `@llvm.experimental.widenable.condition` has semantics of an `undef`, but the intrinsic prevents the optimizer from folding it early. This form should exploit all optimization boons provided to `br` instuction, and it still can be widened by replacing the result of `@llvm.experimental.widenable.condition()` with `and` with any arbitrary boolean value (as long as the branch that is taken when it is `false` has a deopt and has no side-effects). For more motivation, please check llvm-dev discussion "[llvm-dev] Giving up using implicit control flow in guards". This patch introduces this new intrinsic with respective LangRef changes and a pass that converts old-style guards (expressed as intrinsics) into the new form. The naming discussion is still ungoing. Merging this to unblock further items. We can later change the name of this intrinsic. Reviewed By: reames, fedor.sergeev, sanjoy Differential Revision: https://reviews.llvm.org/D51207 llvm-svn: 348593
* [LICM] Reapply r347776 "Make LICM able to hoist phis" with fixJohn Brawn2018-11-291-0/+1351
| | | | | | | | | | This commit caused a large compile-time slowdown in some cases when NDEBUG is off due to the dominator tree verification it added. Fix this by only doing dominator tree and loop info verification when something has been hoisted. Differential Revision: https://reviews.llvm.org/D52827 llvm-svn: 347889
* Revert "[LICM] Enable control flow hoisting by default" and "[LICM] Reapply ↵Martin Storsjo2018-11-291-1351/+0
| | | | | | | | | | | r347190 "Make LICM able to hoist phis" with fix" This reverts commits r347776 and r347778. The first one, r347776, caused significant compile time regressions for certain input files, see PR39836 for details. llvm-svn: 347867
* [LICM] Enable control flow hoisting by defaultJohn Brawn2018-11-281-2/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D54949 llvm-svn: 347778
* [LICM] Reapply r347190 "Make LICM able to hoist phis" with fixJohn Brawn2018-11-281-0/+1351
| | | | | | | | | | | | | | | This commit caused failures because it failed to correctly handle cases where we hoist a phi, then hoist a use of that phi, then have to rehoist that use. We need to make sure that we rehoist the use to _after_ the hoisted phi, which we do by always rehoisting to the immediate dominator instead of just rehoisting everything to the original preheader. An option is also added to control whether control flow is hoisted, which is off in this commit but will be turned on in a subsequent commit. Differential Revision: https://reviews.llvm.org/D52827 llvm-svn: 347776
* [LoopSink] Add preheader to alias setGuozhi Wei2018-11-201-0/+37
| | | | | | | | | | This patch fixes PR39695. The original LoopSink only considers memory alias in loop body. But PR39695 shows that instructions following sink candidate in preheader should also be checked. This is a conservative patch, it simply adds whole preheader block to alias set. It may lose some optimization opportunity, but I think that is very rare because: 1 in the most common case st/ld to the same address, the load should already be optimized away. 2 usually preheader is not very large. Differential Revision: https://reviews.llvm.org/D54659 llvm-svn: 347325
* Revert "[LICM] Make LICM able to hoist phis"Benjamin Kramer2018-11-191-1164/+0
| | | | | | This reverts commit r347190. llvm-svn: 347225
* [LICM] Make LICM able to hoist phisJohn Brawn2018-11-191-0/+1164
| | | | | | | | | | | | | | | The general approach taken is to make note of loop invariant branches, then when we see something conditional on that branch, such as a phi, we create a copy of the branch and (empty versions of) its successors and hoist using that. This has no impact by itself that I've been able to see, as LICM typically doesn't see such phis as they will have been converted into selects by the time LICM is run, but once we start doing phi-to-select conversion later it will be important. Differential Revision: https://reviews.llvm.org/D52827 llvm-svn: 347190
* [LICM] Hoist guards from non-header blocksMax Kazantsev2018-11-121-2/+150
| | | | | | | | | | | This patch relaxes overconservative checks on whether or not we could write memory before we execute an instruction. This allows us to hoist guards out of loops even if they are not in the header block. Differential Revision: https://reviews.llvm.org/D50891 Reviewed By: fedor.sergeev llvm-svn: 346643
* [LoopSink] Do not sink instructions into non-cold blocksMandeep Singh Grang2018-11-071-0/+112
| | | | | | | | | | | | | | Summary: This fixes PR39570. Reviewers: danielcdh, rnk, bkramer Reviewed By: rnk Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D54181 llvm-svn: 346337
* [LICM] Use ICFLoopSafetyInfo in LICMMax Kazantsev2018-11-064-5/+198
| | | | | | | | | | | | | | | This patch makes LICM use `ICFLoopSafetyInfo` that is a smarter version of LoopSafetyInfo that leverages power of Implicit Control Flow Tracking to keep track of throwing instructions and give less pessimistic answers to queries related to throws. The ICFLoopSafetyInfo itself has been introduced in rL344601. This patch enables it in LICM only. Differential Revision: https://reviews.llvm.org/D50377 Reviewed By: apilipenko llvm-svn: 346201
OpenPOWER on IntegriCloud