[PATCH] D17314: Update langref to indicate that calls may be convergent.

[Justin Lebar via llvm-commits]

jlebar added a comment.

In http://reviews.llvm.org/D17314#354379, @joker.eph wrote:

> What happens on inline?


We can clarify this if you want (there are no restrictions on inlining a call to a convergent function), but inasmuch as it's unclear, I think it may speak to a larger problem with the way we're describing this, and I'm afraid that calling out inlining specifically may just paper over the issue.  For example, what about outlining?  Someone more familiar with LLVM than I can probably come up with other edge cases.

The most concrete way I have to explain this is something like:

> There are certain instructions, e.g. llvm.cuda.syncthreads(), that must never be made control-flow dependent on additional values.  This applies transitively through function calls (so long as they are marked convergent).  That is, if a call is convergent, then we must behave as though the call will trigger a convergent instruction (unless we can prove otherwise), and therefore we can't make the call control-flow dependent on additional values, because that would make our putative convergent instruction control-flow dependent on additional values.


I think this makes it relatively clear that inlining/outlining is OK -- the issue is just that you can't put additional control-dependencies in the way of an eventual call to syncthreads.  This is also how I'd explain this notion of convergence to someone IRL.

As I see it, the problem as currently written is that we make no distinction between different "types" of convergent functions.  But we can remove "convergent" from any function which doesn't invoke any convergent functions...so is it turtles all the way down?  Like, if you can see the full program source, can you just drop "convergent" everywhere?  Clearly not, because there are leaves: these special instructions such as syncthreads.  If it weren't for these leaves, we really *could* drop convergent everywhere, in the presence of full source.

In the spec we treat these special instructions the same as functions that you can't see the source of, and I grant that they behave the same, from the perspective of the compiler.  But to at least one human, they're not at all the same.  If we could agree on clarifying that, I think we might make this whole thing a lot better.

But if we can't, I'll just add a note about inlining.  :)


http://reviews.llvm.org/D17314