From what I see it should work. The only thing worries me is that this isCorrectType seems to be not incorporated into solution but some side hack to solve the problem.
Unfortunately at this moment I do not have a better suggestion :(

Changes according to review.

in favor of https://reviews.llvm.org/D77130

Philip, thank you for your suggestion.

Please take a loot at https://reviews.llvm.org/D77122 and https://reviews.llvm.org/D77130.

In D77036#1950340, @reames wrote:

Er, I think the specification simplify needs changed here. As we've discussed offline, it's impossible to enforce having a gc pointer in the deopt list always be in the gc list (in any form). This was a flaw in the specification from the begging and we should fix the docs, not try to hack up the code to preserve it a bit longer.

The key example of why this can't work:
%p1 = bitcast i8* %p to i8*
statepoint [gc = (%p1)], [deopt = (%p1)]

The optimizer is allowed to replace either use (or both) of %p1 with %p. If it updates only one of the two (entirely legal), the two sets do not overlap.

If we need to enforce a property for GC values within deopt list, we should directly use the type of the pointer in question. Anything else appears unsound.

Need to think about other approach

LGTM

without this patch I get the following crash (which disappears with it):

Here is a simple test showing the problem:

May I ask you to add a support for new pass manager to specify new introduced option in command line?

Please wait for one or two days before landing for comments from others.

paranoia: Consider splitting this patch into two parts. The first one by default disables multi-exit, while the second one just switch flag on.

Good catch.

In D72732#1821201, @fedor.sergeev wrote:

In D72732#1821154, @skatkov wrote:

Don't you want to add a code to be able to set GVN options from command line for new pass manager? Or it is a follow-up change?

That should go as a followup.
I did not plan to do that right now, but well, you got a point.
Will post a review for that.

Don't you want to add a code to be able to set GVN options from command line for new pass manager? Or it is a follow-up change?

In D70104#1753816, @twoh wrote:

Addressing comments from @skatkov. Thank you for your review!

For X86 asm tests, I just re-ran update_llc_test_checks.py script. I think it should generate "correct" test based on the existing FileCheck patterns?

@manmanren, could you please ensure that your test still checks what it expected to do?

The implementation itself looks good to me.
I worry about tests whether fixes of the tests are expected.
If you have ready answers please let me know otherwise I'll try to dig into them deeply.

Thanks.

The last thing. Would not you like to add a test examine the max-dedicate-exit-iterations functionality?

More tests are added.

In D67207#1660225, @brzycki wrote:

Hello @skatkov , I'm sorry to hear you're dealing with an intermittent crash. If you find a reproducible .ll file you can feed into opt -jump-threading -S < input.ll that crashes I would be interested in examining it. The Deferred usage of DTU causes unexpected issues and it is entirely possible there is still a bug here.

(CC'ing @kuhar and @NutshellySima to keep them informed)

In D67359#1664242, @wmi wrote:

In D67359#1664241, @skatkov wrote:

I wonder whether the problem is in this function or in analysis itself?
If it is a problem of analysis it is better to restrict it but not an utility function.

I feel the problem is in the utility function. Currently the problem is exposed in IVUser pass but the same can happen anywhere else if only the function is called for a huge loop with many exits and with each exit having many predecessors.

I wonder whether the problem is in this function or in analysis itself?
If it is a problem of analysis it is better to restrict it but not an utility function.

Thank you guys, for feedback.

Note: I've got the crash by changing the DomTreeUpdater form Lazy mode to Eager. Even with this fix it will not work because of LVI->eraseBlock(&BB);
It seems the code is written in the way DTU cannot be Eager.

Please provide a quick fix or revert the patch causing the crash due to transforming to incorrect IR.

Please provide a quick fix or revert the patch causing the crash due to transforming to incorrect IR.

Abandon in favor of https://reviews.llvm.org/D64972

Abandon in favor of https://reviews.llvm.org/D64972

In D64972#1607998, @skatkov wrote:

In D64972#1607909, @skatkov wrote:

Philip, please take a look at https://reviews.llvm.org/D65501 which introduces the peeling level as possible solution to handle your comment.

See https://reviews.llvm.org/D65503. It is the same patch but based on D65501.

In D64972#1607909, @skatkov wrote:

Philip, please take a look at https://reviews.llvm.org/D65501 which introduces the peeling level as possible solution to handle your comment.

Philip, please take a look at https://reviews.llvm.org/D65501 which introduces the peeling level as possible solution to handle your comment.

In D64972#1606836, @reames wrote:

Having both the enable flag and the AlreadyPeeled variable is really confusing. Is there a way we could combine them? Maybe replace the boolean with the AlreadyPeeledViaProfiling count or something?