[PATCH] D38113: OpenCL: Assume functions are convergent

Anastasia Stulova via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Sep 22 04:27:52 PDT 2017


Anastasia added a comment.

In https://reviews.llvm.org/D38113#877906, @jlebar wrote:

> > The problem of adding this attribute conservatively for all functions is that it prevents some optimizations to happen.
>
> function-attrs removes the convergent attribute from anything it can prove does not call a convergent function.
>
> I agree this is a nonoptimal solution.  A better way would be to assume that any cuda/opencl function is convergent and then figure out what isn't.  This would let you generate correct cuda/opencl code in a front-end without worrying about this attribute.
>
> One problem with this approach is, suppose you call an external function, whose body llvm cannot see.  We need some way to mark this function as not-convergent, so that its callers can also be inferred to be not convergent.  LLVM currently only has a "convergent" attribute.  In the absence of a new "not-convergent" attribute, the only way we can tell LLVM that this external function is not convergent is to leave off the attribute.  But then this means we assume all functions without the convergent attribute are not convergent, and thus we have to add the attribute everywhere, as this patch does.
>
> OTOH if we added a not-convergent attribute, we'd have to have rules about what happens if both attributes are on a function, and everywhere that checked whether a function was convergent would become significantly more complicated.  I'm not sure that's worthwhile.


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.

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. Btw, what is the advantage of having "non-convergent" instead and why is the deduction of convergent property more complicated with it?


https://reviews.llvm.org/D38113





More information about the cfe-commits mailing list