[PATCH] D38113: OpenCL: Assume functions are convergent

[Justin Lebar via Phabricator via cfe-commits]

jlebar added a comment.

> Yes, that's why if it would be responsibility of the kernel developer to specify this explicitly we could avoid this complications in the compiler. But if we add it into the language now we still need to support the correctness for the code written with the earlier standards. And also it adds the complexity to the programmer to make sure it's specified correctly. But I think it is still worth discussing with the spec committee.

To me this seems like a small complication in the compiler to avoid an extremely easy bug for users to write.  But, not my language.  :)

> The deduction of convergent is indeed tricky. So if there is any function in the CFG path which is marked as convergent ( or "non-convergent") this will have to be back propagated to the callers unless we force to explicitly specify it but it would be too error prone for the kernel writers I guess.

This probably isn't the right forum to discuss proposals to change the LLVM IR spec.  But if you want to propose something like this, please cc me on the thread, I probably have opinions.  :)

> Btw, what is the advantage of having "non-convergent" instead and why is the deduction of convergent property more complicated with it?

The advantage of switching LLVM IR to non-convergent would be that front-ends wouldn't have the bug that arsenm is fixing here.  "Unadorned" IR would be correct.  And, in the absence of external or unanalyzable indirect calls, you'd get the same performance as we get today even if you had no annotations.

The complexity I was referring to occurs if you add the non-convergent attribute and keep the convergent attr.  I don't think we want that.

But I'm not really proposing a change to the convergent attribute in LLVM IR -- it's probably better to leave it as-is, since we all understand how it works, it ain't broke.


https://reviews.llvm.org/D38113