Seems fine, though I think it would have to be programUndefinedIfFullPoison.

In D12246#235587, @resistor wrote:

I don’t think the example code here is legal under any SPMD models I am aware of. It’s generally not legal to have barrier operations under divergent control flow, such as divergent trip-count loops.

From the CUDA docs:

__syncthreads() is allowed in conditional code but only if the conditional evaluates identically across the entire thread block, otherwise the code execution is likely to hang or produce unintended side effects.

—Owen

In D12377#233658, @arsenm wrote:

If you make the generic min/max nodes legal, you don't need to do this pattern matching yourself

Use isSignedIntSetCC() to simplify logic.

I think we'd need a change in loop unrolling for this. Here's an example, where the trip count is divergent:

Thank you to Sanjoy for the review!

LGTM.

Address Sanjoy's comments.

Closed by commit at http://reviews.llvm.org/rL244166 .

Differential Revision: http://reviews.llvm.org/D11774

Another tiny improvement to the comments.

Tiny comment improvement. Thanks to Jingyue for pointing out that the comment was ambiguous.

Add @notkernel2 test.

Address eliben's comments.

Thank you to Sanjoy and Andy for the review.

Tiny update to comments.

Improve handling of case where V is a ConstantExpr in createSCEV.

LGTM.

Change comments to avoid referring to what this change does as "analysis".

I'd wait to see what reames thinks, but this looks good to me.

In D11212#208037, @sanjoy wrote: [...]

Side comment and optional: have you bootstrapped clang with this change? That's a good sanity check for this sort of change. You may consider bootstrapping with ubsan / asan too to get some extra coverage: the extra control flow the sanitizers add tends to shake out a lot of bugs.

Comments addressed and ran clang-format.

Thanks for the comments, Sanjoy. I'll update the code with name changes Monday.

In D11212#206138, @hfinkel wrote:

In D11212#206104, @broune wrote:

Added and used isGuaranteedToTransferExecutionToSuccessor (is there a better name?). Also slight improvement to comments.

I checked all the instructions in the langref to see if any others might also not terminate. All I found is that while the langref doesn't explicitly say so, some atomics like atomicrmw do not necessarily terminate if another thread keeps interfering. Looking at the C++14 standard, some thread is guaranteed to make progress but I could not find a statement that any given thread is guaranteed to make progress, so I made isGuaranteedToTransferExecutionToSuccessor conservative on that point.

I think we'll end up needing some additional attribute to let us get the C++ semantics at the IR level, and we do want them, but we also need to support languages like Java where infinite loops are (sadly) well defined. Regarding C++, 1.10p27 says:

The implementation may assume that any thread will eventually do one of the following:
  terminate
  make a call to a library I/O function
  access or modify a volatile object, or
  perform a synchronization operation or an atomic operation

 [Note: This is intended to allow compiler transformations such as removal of empty loops, even
  when termination cannot be proven. — end note ]

And, thus, when we can assume C++ semantics, any thread is guaranteed to make progress, or call some external function, or access a volatile/atomic variable.

Addresses David Majnemer's comment on shl.

Added and used isGuaranteedToTransferExecutionToSuccessor (is there a better name?). Also slight improvement to comments.

Address Sanjoy's initial comments.

LGTM.

Committed as revision 240438.

Friendly ping.

Friendly ping.

Add comment on MaxSize.

Change unswitching cost calculation from std::min(NumInstructions, 5 * NumBlocks) to NumInstructions.

The real, fixed revision is at D10376. Ignore this one.

Phabricator tells me to make a new revision instead, this time adding llvm-commits as a subscriber, so I'll do that.

Looks good to me.

Fix typo.

Remove speculation flag and call from PassManagerBuilder.
Update comments on speculation.

LGTM

Change first parameter type of ComputeSpeculationCost to Instruction *.

I promised to get back to you on a few things. I tried these versions overnight:

Use TTI for speculation cost of whitelisted instructions.

Use getSingleSuccessor() more.

Added and used BasicBlock::getSingleSuccessor().
Improved flag descriptions.

In D9360#163642, @majnemer wrote:

It seems this pass has a good deal in common with SimplifyCFG. How is this
pass different from bumping up the cost threshold in that pass?

I added some comments not directly related to the patch, since you're the author of the whole pass, but feel free to ignore those parts for this patch.