[llvm-dev] [RFC] Refinement of convergent semantics

Owen Anderson via llvm-dev
2015-09-08T16:36:55Z

> On Sep 5, 2015, at 1:02 AM, Sanjoy Das <sanjoy at
playingwithpointers.com> wrote:
>
>> The proposed change is to split the semantics of convergent into two
>> annotations:
>>
>> convergent - this operation may not be made control dependent on any
>> additional values (aka may not be sunk into a condition)
>
> Does every unknown function need to be conservatively considered
> containing a convergent operation?  IOW, I'd want LLVM to unswitch
> this:
>
> for (…) {
>   if (c) { … }
>   call (*func_ptr)();
> }
>
> but (*func_ptr)() may contain a convergent operation in it (and it may
> later get devirtualized and inlined).

I expect SPMD implementations built on top of LLVM will need to conservatively
mark external or indirect calls as convergent.

> Also, how about transforms like these:
>
>  if (a & b)
>    convergent();
>
> ==>
>
>  if (a)
>    if (b)
>      convergent();
>
> ?

This should be allowed, as the call was already control dependent on both a and
b.

>> nospeculate - this operation may not be added to any program trace
>> on which it was not previously executed (same as notrap?)
>
> How is this different from, say, a store to the heap?  Or a volatile
> load?  If not, maybe nospeculate operations can just be modeled as
> writing to the heap?

They’re more akin to integer divisions.  They may in fact be purely arithmetic
operations (say, computing a cross-thread gradient), and treating them like heap
stores will significantly over-pessimize the program.

—Owen