[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