Friendly ping.

Address @asbirlea comments

@dmgreen Thanks for the pointer. I think https://reviews.llvm.org/D48202 will define away the problem. I will abandon this patch.

I think this makes sense. Except Jumpthreading needs to be modified to make sure iterator is valid after merging. I can work on the jump threading part once this lands and if you do not mind @brzycki.

Remove some duplicate code.

run clang-format

Handle when all destinations are null (i.e. UNDEF value). There is a slight change in pr22086.ll this is due
to we do not run SimplifyInstructionsInBlock after folding (we run after threading).

I am having some trouble with arc. Created this diff accidentally. Its a duplicate of https://reviews.llvm.org/D48181

@davide @fhahn I am sorry that I cant provide the source code. But one of the cases that resulted in chasing up the chain a lot I can see came from a sequence of object declarations & initializations (constructors which can throw). And they cascaded into a block with 2 predecessors.

Will do.

And I think adding an assert to check against queries w.r.t. dominance makes sense.

@dberlin @reames I completely agree with the diagnosis and the proposed solution. Let me fix this.

Simplify test. I could not get rid of the inttoptr though.

Ping. Thanks.

Remove empty lines.

@davide @fhahn I will take a look!.

In D45608#1067141, @junbuml wrote:

Thanks for handling this. Just curious if you see any issue with the non-null attribute in a constant ?

Address comments.

Address stylistic comments.

@courbet Ping. Thanks

Update checks in a test case.

Simplify how split instructions are moved.

Update an assert.

Address comment.

Friendly Ping.

Update comment in a test

Add a DEBUG msg.

I do not think this is correct. sorry for the noise.

@gottesmm can you please take a look ? Thanks.

In D38563#888831, @davidxl wrote:

A test case?

Thanks for the suggestions and review so far. I am in middle of a project. I will put this on hold for a couple of weeks and will come back to it.

This is no longer necessary as discussed on the list.

In D34823#795758, @dberlin wrote:

Without a reason to do this specifically, it seems a waste of time

None of this data is used after initial building, and all of these are destroyed after newgvn ends, so updating them doesn't seem to accomplish anything?

In D32720#794481, @efriedma wrote:

Thinking about it a bit more, instead of storing a list of instructions which can exit the loop early, you could store a list of basic blocks which are guaranteed to execute, and a mapping from those basic blocks to the first instruction in each basic block which could exit early. That would allow "constant-time" lookups, at the expense of a bit more computation upfront.

I agree it doesn't make sense to try to recompute if an early exit is erased; that should be very rare. (Granted, it might be a little bit more common than it should be: it looks like isGuaranteedToTransferExecutionToSuccessor is missing a few important cases which isInstructionTriviallyDead catches.)