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

[Owen Anderson via llvm-dev]

> 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