mzolotukhin (Michael Zolotukhin)
User

Projects

User does not belong to any projects.

User Details

User Since
Dec 5 2014, 3:20 PM (167 w, 3 d)

Recent Activity

Tue, Feb 6

mzolotukhin committed rL324451: The xfailed test from r324448 passed on one of the bots: remove it entirely for….
The xfailed test from r324448 passed on one of the bots: remove it entirely for…
Tue, Feb 6, 10:56 PM
mzolotukhin committed rL324448: Xfail the test added in r324445 until the underlying issue in LoopSink is fixed..
Xfail the test added in r324445 until the underlying issue in LoopSink is fixed.
Tue, Feb 6, 10:14 PM
mzolotukhin committed rL324445: Follow-up for r324429: "[LCSSAVerification] Run verification only when asserts….
Follow-up for r324429: "[LCSSAVerification] Run verification only when asserts…
Tue, Feb 6, 8:27 PM
mzolotukhin committed rL324429: [LCSSAVerification] Run verification only when asserts are enabled..
[LCSSAVerification] Run verification only when asserts are enabled.
Tue, Feb 6, 4:15 PM

Fri, Jan 26

mzolotukhin accepted D42451: [GlobalOpt] Fix exponential compile-time with selects..

The change looks reasonable to me. Though I wonder if it's possible to trigger a similar exponential behavior with GEP instructions - if that's possible, we should put them to VisitedUsers too.

Fri, Jan 26, 3:03 PM

Tue, Jan 23

mzolotukhin added a comment to D38313: [InstCombine] Introducing Aggressive Instruction Combine pass.

No concerns from my side, thanks for making the change!

Tue, Jan 23, 11:28 AM

Jan 15 2018

mzolotukhin added a comment to D38313: [InstCombine] Introducing Aggressive Instruction Combine pass.

As you said, the pass spend very little time, cannot we decide on moving it to -O3 in the future when/if other heavy optimizations is added to this pass?
And even then, we can decide to run part of them on -O2 and the rest on -O3.

My main concern with that is that it's actually really hard to demote something to lower optlevels retroactively.

Jan 15 2018, 10:47 AM

Jan 9 2018

mzolotukhin added a comment to D38313: [InstCombine] Introducing Aggressive Instruction Combine pass.

Hi and sorry for the late reply, I've just returned from the holidays break.
The numbers posted before look good. I wonder though if it would make sense to only run this pass on -O3. I assume that even if now the pass spends very little time, it will grow in future and the compile-time costs might become noticeable.

Jan 9 2018, 5:58 PM
mzolotukhin committed rL322137: [LoopRotate] Detect loops with indirect branches better (we're giving up on….
[LoopRotate] Detect loops with indirect branches better (we're giving up on…
Jan 9 2018, 3:55 PM

Dec 20 2017

mzolotukhin added a comment to D41361: [SimplifyCFG] Avoid quadratic on a predecessors number behavior in instruction sinking..

Thanks for review!
Phabricator didn't catch the review thread. The patch was committed in rL321236.

Dec 20 2017, 5:25 PM
mzolotukhin closed D41361: [SimplifyCFG] Avoid quadratic on a predecessors number behavior in instruction sinking..
Dec 20 2017, 5:24 PM
mzolotukhin committed rL321236: [SimplifyCFG] Avoid quadratic on a predecessors number behavior in instruction….
[SimplifyCFG] Avoid quadratic on a predecessors number behavior in instruction…
Dec 20 2017, 5:23 PM
mzolotukhin updated the diff for D41361: [SimplifyCFG] Avoid quadratic on a predecessors number behavior in instruction sinking..

Rebase.

Dec 20 2017, 5:03 PM
mzolotukhin added a comment to D41361: [SimplifyCFG] Avoid quadratic on a predecessors number behavior in instruction sinking..

Yes, I'm not really worried about that aspect; I'm more concerned that the transform somehow isn't triggering in cases where it should.

I just tried digging a bit; it looks like the generated code is worse, particularly for avoid-cpsr-rmw.ll. I'm not sure that's really the fault of this patch, exactly... it looks like the sinking does in fact happen, but the end result is different because of related transforms. Looks like it's exposing a bad heuristic elsewhere?

Yes, it does behave differently after the patch. However, from code sinking point of view the new behavior seems better to me.

Dec 20 2017, 2:35 PM

Dec 19 2017

mzolotukhin added a comment to D41361: [SimplifyCFG] Avoid quadratic on a predecessors number behavior in instruction sinking..

test/CodeGen/AArch64/arm64-jumptable.ll - changes in this test mimic the changes that previous implementation of SimplifyCFG would do.

With your patch, what transform do we perform here instead of sinking? As far as I can tell, SimplifyCFG doesn't make any other changes.

I don't think SimplifyCFG makes any other changes, but the test isn't for SimplifyCFG - as far as I understand it, it's for instructions we generate in the backend. The test was just written to trigger some specific situation, and with this change it stopped triggering it.

Dec 19 2017, 7:10 PM

Dec 18 2017

mzolotukhin added a comment to D41361: [SimplifyCFG] Avoid quadratic on a predecessors number behavior in instruction sinking..

This also fixes a big compile time regression we found that was caused by rL279460 (and consequent follow-ups). In the problematic test-case we have a huge function, where one of the blocks have more than 1000 predecessors.

Dec 18 2017, 10:54 AM
mzolotukhin created D41361: [SimplifyCFG] Avoid quadratic on a predecessors number behavior in instruction sinking..
Dec 18 2017, 10:47 AM

Dec 13 2017

mzolotukhin committed rL320648: Recover some overzealously removed includes..
Recover some overzealously removed includes.
Dec 13 2017, 2:21 PM
mzolotukhin committed rL320631: Remove redundant includes from tools..
Remove redundant includes from tools.
Dec 13 2017, 1:32 PM
mzolotukhin committed rL320636: Remove redundant includes from lib/Target/X86..
Remove redundant includes from lib/Target/X86.
Dec 13 2017, 1:32 PM
mzolotukhin committed rL320635: Remove redundant includes from lib/Target/ARM..
Remove redundant includes from lib/Target/ARM.
Dec 13 2017, 1:32 PM
mzolotukhin committed rL320634: Remove redundant includes from lib/Target/AArch64..
Remove redundant includes from lib/Target/AArch64.
Dec 13 2017, 1:32 PM
mzolotukhin committed rL320633: Remove redundant includes from lib/Target/*.cpp..
Remove redundant includes from lib/Target/*.cpp.
Dec 13 2017, 1:32 PM
mzolotukhin committed rL320632: Remove redundant includes from utils/TableGen..
Remove redundant includes from utils/TableGen.
Dec 13 2017, 1:32 PM
mzolotukhin committed rL320630: Remove redundant includes from unittests..
Remove redundant includes from unittests.
Dec 13 2017, 1:32 PM
mzolotukhin committed rL320628: Remove redundant includes from lib/Transforms..
Remove redundant includes from lib/Transforms.
Dec 13 2017, 1:32 PM
mzolotukhin committed rL320629: Remove redundant includes from various places..
Remove redundant includes from various places.
Dec 13 2017, 1:32 PM
mzolotukhin committed rL320627: Remove redundant includes from lib/Support..
Remove redundant includes from lib/Support.
Dec 13 2017, 1:31 PM
mzolotukhin committed rL320624: Remove redundant includes from lib/MC..
Remove redundant includes from lib/MC.
Dec 13 2017, 1:31 PM
mzolotukhin committed rL320626: Remove redundant includes from lib/ProfileData..
Remove redundant includes from lib/ProfileData.
Dec 13 2017, 1:31 PM
mzolotukhin committed rL320625: Remove redundant includes from lib/Object..
Remove redundant includes from lib/Object.
Dec 13 2017, 1:31 PM
mzolotukhin committed rL320623: Remove redundant includes from lib/LTO..
Remove redundant includes from lib/LTO.
Dec 13 2017, 1:31 PM
mzolotukhin committed rL320619: Remove redundant includes from lib/CodeGen..
Remove redundant includes from lib/CodeGen.
Dec 13 2017, 1:31 PM
mzolotukhin committed rL320622: Remove redundant includes from lib/IR..
Remove redundant includes from lib/IR.
Dec 13 2017, 1:31 PM
mzolotukhin committed rL320620: Remove redundant includes from lib/DebugInfo..
Remove redundant includes from lib/DebugInfo.
Dec 13 2017, 1:31 PM
mzolotukhin committed rL320621: Remove redundant includes from lib/ExecutionEngine..
Remove redundant includes from lib/ExecutionEngine.
Dec 13 2017, 1:31 PM
mzolotukhin committed rL320618: Remove redundant includes from lib/Bitcode..
Remove redundant includes from lib/Bitcode.
Dec 13 2017, 1:31 PM
mzolotukhin committed rL320617: Remove redundant includes from lib/Analysis..
Remove redundant includes from lib/Analysis.
Dec 13 2017, 1:31 PM

Oct 17 2017

mzolotukhin committed rL316045: [GlobalDCE] Use DenseMap instead of unordered_multimap for GVDependencies..
[GlobalDCE] Use DenseMap instead of unordered_multimap for GVDependencies.
Oct 17 2017, 4:47 PM
mzolotukhin closed D38916: [GlobalDCE] Use DenseMap instead of unordered_multimap for GVDependencies. by committing rL316045: [GlobalDCE] Use DenseMap instead of unordered_multimap for GVDependencies..
Oct 17 2017, 4:47 PM
mzolotukhin added a comment to D38916: [GlobalDCE] Use DenseMap instead of unordered_multimap for GVDependencies..

Thanks!

Oct 17 2017, 3:16 PM
mzolotukhin added a comment to D38916: [GlobalDCE] Use DenseMap instead of unordered_multimap for GVDependencies..

Is the patch ok to commit?

Oct 17 2017, 3:06 PM

Oct 13 2017

mzolotukhin added a comment to D38916: [GlobalDCE] Use DenseMap instead of unordered_multimap for GVDependencies..

Generally switching to generic containers to LLVM ones lead to improvements, but 17x seems quite large to me (not complaining).

17x probably comes from the test being huge: when we're building with LTO, we're getting a ~50Mb bitcode file.

Oct 13 2017, 6:06 PM
mzolotukhin created D38916: [GlobalDCE] Use DenseMap instead of unordered_multimap for GVDependencies..
Oct 13 2017, 5:54 PM

Oct 4 2017

mzolotukhin added a comment to D38154: [PassManager] Run global opts after the inliner.

How do you get the diff out of curiosity?

It's produced by the compare.py script:

python test-suite/utils/compare.py -m compile_time unpatched.json patched.json
python test-suite/utils/compare.py -m size unpatched.json patched.json

But to run it, you first will need pip install pandas, which can take up to 10 minutes :)

Oct 4 2017, 3:07 PM
mzolotukhin added a comment to D38154: [PassManager] Run global opts after the inliner.

Hm, from the files you uploaded I don't see a slowdown on 7zip, but see some others. Are we talking about the same numbers?:)

Oct 4 2017, 2:17 PM

Oct 3 2017

mzolotukhin added a comment to D38154: [PassManager] Run global opts after the inliner.

Which part is cumbersome?

I was talking about compare.py specifically. Namely, it uses pandas package, which is not as commonly installed as others, and installing it wasn't very easy/fast if I remember it correctly. All I wanted to say is that these tools are required some getting used to and might not work from the first try, and in case of compare.py you might want to not use if you only need to do it once.

Oct 3 2017, 11:08 AM

Oct 2 2017

mzolotukhin added a comment to D38154: [PassManager] Run global opts after the inliner.

I'd recommend using LNT, here is a script with full ground-up setup for your convenience:

cd tmp
Oct 2 2017, 9:57 PM
mzolotukhin added a comment to D38154: [PassManager] Run global opts after the inliner.

Hi Davide,

Oct 2 2017, 5:51 PM

Aug 28 2017

mzolotukhin added a comment to D37153: [LoopUnroll] Properly update loop structure in case of successful peeling.

I added a cl::opt...

You seemed to forget to use it in the test though :)

Aug 28 2017, 5:44 PM
mzolotukhin added a comment to D37153: [LoopUnroll] Properly update loop structure in case of successful peeling.

FWIW, this only triggers with SystemZ as triple (probably because it sets peeling parameters differently?).

Yeah, that's probably the reason. I suggest to (find and) pass the necessary parameters explicitly so we don't depend on target preferences at all.

Aug 28 2017, 11:47 AM
mzolotukhin added a comment to D37153: [LoopUnroll] Properly update loop structure in case of successful peeling.

The change looks good to me, but I'd like to see a more simplified test. We probably don't need 90% of its instructions, and also it doesn't need to be SystemZ-specific.

Aug 28 2017, 11:32 AM

Aug 22 2017

mzolotukhin committed rL311493: cmake/caches: Add caches for Os and O3 with debug info..
cmake/caches: Add caches for Os and O3 with debug info.
Aug 22 2017, 2:45 PM

Aug 10 2017

mzolotukhin added a comment to D36492: [time-report] Add preprocessor timer.

FWIW, I strongly support the idea of adding more detailed timers into the frontend. Thanks for working on it!
I probably won't be very helpful in reviewing this code, but I'd appreciate if you CC me in the future patches.

Aug 10 2017, 12:29 PM

Jul 25 2017

mzolotukhin accepted D35827: [SCEV] Cache results of computeExitLimit.

Looks good to me. Out of curiosity, does the patch improve compile time on usual tests (rather than on corner cases)?

Jul 25 2017, 5:17 AM
mzolotukhin committed rL308964: [tests] Cleanup vect.omp.persistence.ll test..
[tests] Cleanup vect.omp.persistence.ll test.
Jul 25 2017, 3:36 AM

Jul 12 2017

mzolotukhin accepted D35304: [RuntimeLoopUnrolling] Update DomTree correctly when exit blocks have successors.

Does this answer your question?

Yes, thank you for the detailed answer. The patch looks good to me then (please also find some minor comments/suggestions inline).

Jul 12 2017, 2:52 PM
mzolotukhin added a comment to D35304: [RuntimeLoopUnrolling] Update DomTree correctly when exit blocks have successors.

Don't we break critical edges before unrolling? If so, then I think this situation should never happen (and if it does, we need to understand why).

Jul 12 2017, 1:51 PM

Jul 6 2017

mzolotukhin added a comment to D34841: [lit/libcxx] Fix a remaining reference to lit.util.capture() in custom libcxx/Darwin code..

Do you have any hints for how I might be able to tickle the errors you found?

I found this issue in our regular 2 stage PGO build (generate-profraw target from tools/clang/utils/perf-training/CMakeLists.txt invokes LIT tests). I think we should just replace all appearances of lit.util.capture with subprocess.check_output - at least, it shouldn't make things worse.

Jul 6 2017, 1:58 PM

Jul 5 2017

mzolotukhin added a comment to D34841: [lit/libcxx] Fix a remaining reference to lit.util.capture() in custom libcxx/Darwin code..

There are still more uses of lit.util.capture. I fixed one of them in r307201 (it broke PGO builds), but there are still some remaining:

./test/lit.cfg:    llvm_src_root = lit.util.capture(['llvm-config', '--src-root']).strip()
./test/lit.cfg:    llvm_obj_root = lit.util.capture(['llvm-config', '--obj-root']).strip()
./test/Unit/lit.cfg:    llvm_src_root = lit.util.capture(['llvm-config', '--src-root']).strip()
./test/Unit/lit.cfg:    llvm_obj_root = lit.util.capture(['llvm-config', '--obj-root']).strip()
./tools/clang/test/lit.cfg:    llvm_src_root = lit.util.capture(['llvm-config', '--src-root']).strip()
./tools/clang/test/lit.cfg:    llvm_obj_root = lit.util.capture(['llvm-config', '--obj-root']).strip()
./tools/clang/test/Unit/lit.cfg:    llvm_src_root = lit.util.capture(['llvm-config', '--src-root']).strip()
./tools/clang/test/Unit/lit.cfg:    llvm_obj_root = lit.util.capture(['llvm-config', '--obj-root']).strip()

I wonder why they didn't cause any problems (or why we didn't find the problems). Do we need to change them the same way?

Jul 5 2017, 2:14 PM
mzolotukhin committed rL307201: Fix one more reference to lit.util.capture().
Fix one more reference to lit.util.capture()
Jul 5 2017, 2:06 PM

Jun 29 2017

mzolotukhin accepted D34841: [lit/libcxx] Fix a remaining reference to lit.util.capture() in custom libcxx/Darwin code..

Looks good to me (see one comment below)!

Jun 29 2017, 4:04 PM
mzolotukhin added a comment to D34792: [lit] Remove dead code not referenced in the LLVM SVN repo..

We're seeing more issues (I think they are unrelated to the FileBasedTest issue mentioned before).

Jun 29 2017, 3:18 PM

Jun 28 2017

mzolotukhin committed rL306644: Revert "[LSan] Make LSan allocator allocator_may_return_null compliant".
Revert "[LSan] Make LSan allocator allocator_may_return_null compliant"
Jun 28 2017, 9:39 PM

Jun 12 2017

mzolotukhin added a comment to D30446: [IndVars] Do not branch on poison.

I ran SPEC2006 and CTMark with and without the patches and didn't see any performance difference.

Jun 12 2017, 10:09 PM
mzolotukhin added a comment to D30446: [IndVars] Do not branch on poison.

Sorry for the delay, I missed this thread somehow.
I'm running tests now, and publish the results as soon as I get them.

Jun 12 2017, 5:54 PM

Jun 1 2017

mzolotukhin added a comment to D23388: [LoopUnroll] By default disable unrolling when optimizing for size..

I looked at your benchmarks numbers, with particular attention to the worst regressions, and I'm not convinced these benchmarks are representative.

What about tramp3d-v4 and SPECs? As far as I remember, tramp3d-v4 compiles pretty long and is pretty stable (and it is a part of CTMark).

Jun 1 2017, 12:36 PM

May 23 2017

mzolotukhin added a comment to D23388: [LoopUnroll] By default disable unrolling when optimizing for size..

Hi Davide,

May 23 2017, 3:59 PM

May 4 2017

mzolotukhin committed rL302175: Fix a typo..
Fix a typo.
May 4 2017, 10:55 AM

May 3 2017

mzolotukhin committed rL302096: [SCEV] createAddRecFromPHI: Optimize for the most common case..
[SCEV] createAddRecFromPHI: Optimize for the most common case.
May 3 2017, 5:07 PM
mzolotukhin closed D32663: [SCEV] createAddRecFromPHI: Optimize for the most common case. by committing rL302096: [SCEV] createAddRecFromPHI: Optimize for the most common case..
May 3 2017, 5:06 PM
mzolotukhin added a comment to D32663: [SCEV] createAddRecFromPHI: Optimize for the most common case..

This change is NFC right?

I wanted it to be so, but apparently it's not. See more details in my previous reply.

May 3 2017, 3:52 PM
mzolotukhin updated the diff for D32663: [SCEV] createAddRecFromPHI: Optimize for the most common case..
  • Fix indentation.
May 3 2017, 3:51 PM
mzolotukhin added a comment to D32663: [SCEV] createAddRecFromPHI: Optimize for the most common case..

Thanks for taking a look, I've updated the patch.

May 3 2017, 3:48 PM
mzolotukhin updated the diff for D32663: [SCEV] createAddRecFromPHI: Optimize for the most common case..
  • Address Sanjoy's remarks.
May 3 2017, 3:45 PM

Apr 28 2017

mzolotukhin created D32663: [SCEV] createAddRecFromPHI: Optimize for the most common case..
Apr 28 2017, 4:13 PM
mzolotukhin committed rL301703: [SCEV] Use early exit in createAddRecFromPHI. NFC..
[SCEV] Use early exit in createAddRecFromPHI. NFC.
Apr 28 2017, 3:27 PM

Apr 20 2017

mzolotukhin accepted D32261: [LoopUnroll] Don't try to unroll non-rotated loops.

Thanks for addressing my previous remarks! The change looks good to me (modulo Eli's remark regarding the check).

Apr 20 2017, 5:19 PM

Apr 19 2017

mzolotukhin added inline comments to D32261: [LoopUnroll] Don't try to unroll non-rotated loops.
Apr 19 2017, 5:27 PM

Apr 12 2017

mzolotukhin added a comment to D31843: [LCSSA] Try to not walk the dominator tree more than necessary.

The new patch is here and it's 25% faster than the unpatched version on the testcase included in the PR

Nice!

Apr 12 2017, 7:04 PM

Apr 10 2017

mzolotukhin added a comment to D31843: [LCSSA] Try to not walk the dominator tree more than necessary.

This is precisely equivalent to the stack algorithm i outlined.

I didn't refresh the page before posting, sorry :)

Apr 10 2017, 12:59 PM
mzolotukhin added a comment to D31843: [LCSSA] Try to not walk the dominator tree more than necessary.

If the slow part is checking if the block dominates any exit, how about we precompute set of blocks meeting this requirement in advance?

Apr 10 2017, 12:36 PM

Apr 5 2017

mzolotukhin added a comment to D31730: [LCSSA] Remove redundant check.

Can you verify that by inserting an assertion there?

Apr 5 2017, 3:46 PM

Mar 22 2017

mzolotukhin added a comment to D31239: [WIP] Add Caching of Known Bits in InstCombine.

Thanks for posting this, Hal!

Mar 22 2017, 2:34 PM

Mar 19 2017

mzolotukhin added a comment to D31104: [ConstantRange] Add setSizeSmallerThanOf method..

Thanks for the review, Sanjoy!

Mar 19 2017, 11:55 PM
mzolotukhin committed rL298236: [ConstantRange] Add setSizeSmallerThanOf method..
[ConstantRange] Add setSizeSmallerThanOf method.
Mar 19 2017, 11:45 PM
mzolotukhin closed D31104: [ConstantRange] Add setSizeSmallerThanOf method. by committing rL298236: [ConstantRange] Add setSizeSmallerThanOf method..
Mar 19 2017, 11:45 PM
mzolotukhin updated the diff for D31104: [ConstantRange] Add setSizeSmallerThanOf method..
  • Address review remarks.
Mar 19 2017, 11:10 PM

Mar 17 2017

mzolotukhin created D31104: [ConstantRange] Add setSizeSmallerThanOf method..
Mar 17 2017, 2:15 PM

Mar 16 2017

mzolotukhin committed rL297992: [SCEV] Compute affine range in another way to avoid bitwidth extending..
[SCEV] Compute affine range in another way to avoid bitwidth extending.
Mar 16 2017, 2:19 PM
mzolotukhin closed D30477: [SCEV] Compute affine range in another way to avoid bitwidth extending. by committing rL297992: [SCEV] Compute affine range in another way to avoid bitwidth extending..
Mar 16 2017, 2:19 PM
mzolotukhin added a comment to D30757: [LoopUnroll] Don't peel loops where the latch isn't the exiting block.

This version looks good to me too.

Mar 16 2017, 1:54 PM

Mar 15 2017

mzolotukhin added a comment to D30757: [LoopUnroll] Don't peel loops where the latch isn't the exiting block.

Do you know if we already have a utility somewhere that detects this?

Can we require the loop to be in a simplified form and its latch to be exiting? Will it suffice?

Mar 15 2017, 5:14 PM
mzolotukhin accepted D30757: [LoopUnroll] Don't peel loops where the latch isn't the exiting block.

Looks good to me, but, as you noticed in the PR - do we want to work with such loops at all? Did you check what happens if we just bail out on such loops?

Mar 15 2017, 4:38 PM

Mar 14 2017

mzolotukhin added a comment to D21720: Unroll for uncountable loops.

Okay, so is the general plan here to?

  1. Generally allow unrolling of uncountable loops
  2. Adjust the profitability heuristic to account for the cost of the branches for the uncountable case
  3. Include, as necessary, in our general profitability heuristic (if we don't get this naturally), savings from phi-derived values which are cyclic with a small cycle length (like the s = -s case).

I agree that we should start from (1). But I don't understand, why (2) (and (3) ) is considered special for the uncountable case. AFAIU, the current heuristic aims at simulating these savings (removed branches) already - even though we do not try to accurately predict cost of rolled and unrolled version of the loop. Am I missing something?

Mar 14 2017, 2:28 PM

Mar 11 2017

mzolotukhin added a comment to D30477: [SCEV] Compute affine range in another way to avoid bitwidth extending..

Requesting another iteration mostly because I too want to look at it again with fresh eyes to see if I missed anything.

Absolutely.

Mar 11 2017, 8:40 PM
mzolotukhin updated the diff for D30477: [SCEV] Compute affine range in another way to avoid bitwidth extending..
  • Add a comment about INT_SMIN.
Mar 11 2017, 8:32 PM
mzolotukhin updated the diff for D30477: [SCEV] Compute affine range in another way to avoid bitwidth extending..
  • Address review remarks.
Mar 11 2017, 8:10 PM

Mar 10 2017

mzolotukhin added a comment to D21720: Unroll for uncountable loops.

Uncountable loops where previous value is reused (save one+ instruction for each value)

What do you mean by uncountable? How is it different from a loop with unknown trip count?
What is a previous value? Is it a value from a previous iteration? If that's the case, any induction variable satisfies that condition.

Mar 10 2017, 12:14 PM
mzolotukhin added a comment to D21720: Unroll for uncountable loops.

What is the case 1?

Mar 10 2017, 11:19 AM