[PATCH] D26348: Allow convergent attribute for function arguments

[Nicolai Hähnle via llvm-commits]

nhaehnle added inline comments.


================
Comment at: docs/LangRef.rst:1163
+
+    Two runs r1 and r2 of a program are compatible (wrt convergent function
+    attributes) if for every call site CS with a convergent argument, the
----------------
nhaehnle wrote:
> hfinkel wrote:
> > nhaehnle wrote:
> > > hfinkel wrote:
> > > > Please write out "with respect to." Also, you mean convergent function-parameter attributes, not function attributes.
> > > > 
> > > > The runs of the program terminology I find bothersome, in part because that's not what we're talking about. We're talking about the behavior of different threads within the same program. I think it would be better to say, "Two executions of the calling function, e1 and e2, are compatible..." Then we can say that transformations must preserve compatibility w.r.t. convergent function-parameter attributes for all potential executions of the calling function. We might even further specify that this is for potential simultaneous executions.
> > > > 
> > > > Finally, I'd really like it if you would include the example we've been discussing in the reference as a non-normative example. I did not really understand the definition until I read @nhaehnle's explanation above.
> > > I'm only one person :)
> > > 
> > > I'm making the editing changes and adding the example.
> > > 
> > > s/run/execution/ is fine with me, and I'm adding that as an alternative below, but whenever I try to formulate some text that talks about executing a calling function rather than executing a function, I feel confused about the calling vs. the callee function.
> > > 
> > > Perhaps you can clarify:
> > > 
> > > > The runs of the program terminology I find bothersome, in part because that's not what we're talking about. We're talking about the behavior of different threads within the same program.
> > > 
> > > What's the difference between threads and executions in this context?
> > > but whenever I try to formulate some text that talks about executing a calling function rather than executing a function, I feel confused about the calling vs. the callee function.
> > 
> > Feel free to establish some terminology early in the definition for later use. We're talking about a function-parameter attribute. That attribute must appear on the function parameters of some call site. That call site exists in some function (the caller a.k.a. the calling function) and calls some other function (the callee function).
> > 
> > > What's the difference between threads and executions in this context?
> > 
> > As I think about it, a thread is some entity that executes things (e.g. functions). Threads execute functions, and each time a thread executes some function, that constitutes an execution of that function.
> > 
> I see. I played around with this some more, and here's an example I'd like to hear your thoughts on:
> 
>   define void @foo(i32 %a) {
>     ...
>     call void @bar(i32 %a)
>     ...
>   }
> 
>   define void @bar(i32 %a) {
>     call void @baz(i32 convergent %a)
>   }
> 
> This code has a potential problem because at least the parameter of bar should arguably have been labelled convergent.
> 
> I'd say that inlining shouldn't have to worry about the convergent attribute at all. However, if the definition we're discussing here takes a function-centric view, then we cannot prove in a target-independent way that inlining bar is correct (because foo gets a new callsite with a convergent function argument, where previously there were no such callsites, i.e. //every// pair of runs of foo was compatible). If the definition takes a program-centric view (i.e., executions that start at foo implicitly also consider the sequence of arguments passed into baz inside bar), then inlining bar is clearly correct.
> 
> That would be an argument in favour of staying with the language about "executions of a program" rather than "executions of a function".
Hmm, looking at other transforms of similar cases, I think we have to say that cases like this are undefined behaviour.

Curious, I think the same applies to the convergent attribute for functions: if a function F contains calls to a convergent function G, but is not itself marked convergent, then calls to F should be undefined behaviour, right? LangRef is currently somewhat silent on this particular point.


https://reviews.llvm.org/D26348