LGTM after you address David's comment -- A post-dominates B doesn't guarantee execution that reaches B will arrive A.

Yay! Thanks for testing this!

Have you considered letting Clang (instead of a late-stage IR pass) add these ranges? These ranges are useful for some target-independent IR passes, e.g. those using ValueTracking (D4150).

Looks great! Thanks.

Thanks! I completely missed this case :(

Awesome! Thanks Justin.

In D19518#412546, @andrew.w.kaylor wrote:

In D19518#412434, @jingyue wrote:

Oh, I see what you mean now.

So NVPTXPeephole should be guarded by CodeGenOpt::None and thus is safe to skip.

The optnone-llc.ll test verifies that nothing is skipped which is run at -O0, so as long as this pass is being run at -O0 we can't add the call to skip it for "optnone" functions and bisection. If the target machine code were updated to skip the peephole pass at -O0 then the skip check could be added.

Oh, I see what you mean now.

Hi Andrew,

Maybe change the title to be "... instead of default for pure arithmetic instructions". Otherwise, LGTM!

Thanks!

Should we land this? It will fix PR26185.

Other than that FIXME, pretty straightforward. LGTM

D18168 duplicates this and is submitted.

Thanks for working on this long overdue feature!

All comments addressed. Submitting...

Some more minor changes.

jlebar@'s comments

Thanks a lot for the review! I understand it's a lot of work :) I answered one of your high-level questions. I'm still OOO and will get to other comments later.

I am not clear with this part either. jholewinski@, can you comment on this?

Sorry, I pressed the wrong button. I meant to say "needs revision". Feel free to reclaim this patch.

Pressed the wrong button. Meant to say "needs revision". Feel free to reclaim it.

Oops... I pressed the wrong button. I meant to say "need revision". jmolly@, feel free to reclaim it.

It doesn't work with the new alias analysis infrastructure.

Is this patch obsolete? Are you still trying to push it in?

I am OOO and maybe unable to review this until next week.

Happy!

Lgtm

I'll defer to Justin's approval.

Just a reminder if you haven't done that already, double-check how the web page looks like before you commit.

I was referring to this paragraph

Barriers are executed on a per-warp basis as if all the threads in a warp are active. Thus, if any thread in a warp executes a bar instruction, it is as if all the threads in the warp have executed the bar instruction. All threads in the warp are stalled until the barrier completes, and the arrival count for the barrier is incremented by the warp size (not the number of active threads in the warp). In conditionally executed code, a bar instruction should only be used if it is known that all threads evaluate the condition identically (the warp does not diverge). Since barriers are executed on a per-warp basis, the optional thread count must be a multiple of the warp size.

Read more at: http://docs.nvidia.com/cuda/parallel-thread-execution/index.html#ixzz3zMFDtpKf

LGTM, but do you have a test where LLVM generates wrong code if __syncthreads is not marked convergent?

Committed in r254408.

More comments.

LGTM with some minors

Replace the link to the raw diff with more instructions.

Simplify the command lines and header file inclusion

In D14370#284494, @silvas wrote:

My biggest concern is to avoid giving users the false impression that what is described here is an officially supported long-term interface from clang. Would it be accurate to say that this document is meant for "LLVM developers" (or otherwise people working inside LLVM)?

Other than clarifying that, the content LGTM.

simplify the doc

added cuda_runtime.h

I'll let you do that after this patch. You know much better than me on
those options.