The is the part2 to solve https://llvm.org/bugs/show_bug.cgi?id=10584
For the testcases in the bug, LICM creates many long stretched vars living across many BBs. When CVP queries Lazy Value Information (LVI) for such vars, for each var, LVI would go through all the BBs it lives across. If there are many such long stretched vars, CVP will become very slow. Reg splitting has similar problem. For a vreg with very long live range, computing spill placement when splitting the vreg will take high cost.
The patch tries to throttle LICM to reduce the number of non-expensive instructions being hoisted outside of very large loop. For small loop, hoisting vars outside of such loop will not increase the cost much so we keep the current logic to hoist as many as possible. For large loop, expensive instructions like mul/div/rem/... will still be hoisted anyway. For non-expensive instructions in large loop, we use reg number to throttle how many instructions should be hoisted.
No unittest is added because I cannot find a small testcase for it.
Tested llvm testsuite and google internal benchmark on x86_64-linux-gnu and didn't find perf regression.