[PATCH] D26348: Allow convergent attribute for function arguments

Sanjoy Das via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Dec 9 17:11:42 PST 2016


sanjoy added inline comments.


================
Comment at: docs/LangRef.rst:1199
+    Calling a function F that contains a call-site CS with convergent function
+    arguments is only defined behavior if the only data-dependencies of the
+    convergent function arguments of CS are convergent parameters of F. If this
----------------
mehdi_amini wrote:
> sanjoy wrote:
> > This is a little tricky -- what if the source program is:
> > 
> > ```
> > void f(int convergent i);
> > void g(int convergent j, int /* normal */ k) {
> >   f(j - j + k);
> > }
> > ```
> > 
> > Can we simplify the call site to call `f(k)`?  If so, did we introduce UB in functions that call `g`?
> Isn't your source program already UB? You have a call site with an argument that is data-dependent on a non-convergent parameter, `k`.
> 
> The kind of annoying and SSA-breaking limitation of convergent would be:
> 
> ```
> void f(int convergent i);
> void g(int convergent j, int /* normal */ k) {
>   if (j == k)
>      f(j);
> }
> ```
> 
> You can't replace `f(j);` with `f(k);` IIUC.
> 
> 
You're right, I misread "only data-dependencies" as "there must be at least one convergent data dependencies".

The other interesting corner case here is (assuming I did not misread this second time around) around PHI nodes and selects -- if we have:

```
void @other_convergent(int convergent x);
void @f(int convergent k, int /* normal */ l) {
entry:
  br cond label left, label merge

left:
  br label merge

merge:
  val = PHI [ k, entry ], [ l, left ]
  call @other_convergent(val);
}
```

Is calling the function above well defined if `cond` is is always `false`?  What happens if we convert the phi to a select?  What happens when we convert the select to arithmetic?



https://reviews.llvm.org/D26348





More information about the llvm-commits mailing list