[llvm-dev] RFC: make calls "convergent" by default

[John McCall via llvm-dev]

On 2 Jun 2021, at 20:09, James Y Knight wrote:
> On Wed, Jun 2, 2021 at 4:07 AM John McCall via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> A function that participates and isn’t marked convergent should 
>> probably
>> default to being non-convergent, because that’s the conservative 
>> assumption
>> (I believe). But if a function doesn’t participate in the analysis 
>> at all,
>> well, it just doesn’t apply.
>>
> Based on the name, I agree it does feel like "non-convergent" would be 
> the
> conservative assumption. But IIUC, that's unfortunately not the case, 
> and
> is why this proposal to change the default is being made.
>
> "Convergent" actually means something like "This function *might 
> *depend on
> the alignment of control-flow across multiple threads in order to 
> exchange
> data with the implicit set of neighboring threads which are executing 
> the
> same instruction at the same time". Non-convergent means the opposite: 
> that
> the code -- including any transitive functions it calls -- is known to 
> NOT
> have any such cross-thread interaction.

Oh, sorry, I have the name backwards, then.  If “convergent” means
“this can interact with neighboring threads”, then “convergent” 
is the
conservatively correct default.

> On Tue, Jun 1, 2021 at 7:59 AM Sameer Sahasrabuddhe via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> 2. D69498 will be updated so that the convergent property is made
>>    default, but the new requirements on CPU frontends will be 
>> retracted.
>
>
> If I understand correctly, this means the Clang frontend will no 
> longer
> need to add any convergent NOR noconvergent attributes. Instead, LLVM
> analysis passes can infer the new noconvergent attribute as 
> appropriate.
> And on non-GPU platforms, the analysis can be skipped, and the 
> optimization
> passes can simply ignore convergence attributes, because the hardware 
> has
> no operations which can observe convergence. (So, it doesn't matter 
> whether
> a function is marked noconvergent or not.)
>
> Which is to say: this proposal should make things *easier* for "naive"
> frontends, not harder. By default, a reasonable thing should happen 
> when
> the frontend does nothing -- both on GPU platforms and non-GPU 
> platforms.
> Especially if all of the code is in a single module (e.g., via LTO), 
> there
> will be few calls to unknown destinations, so noconvergent can be 
> inferred
> basically everywhere that is not *in fact* dependent on convergence.

Well, if you really don’t need this to be explicit in IR at all,
that’s different.  But my goal is not to reduce the work required
for frontends when they’re intending to support a particular
feature.  My goal is to better support both mixed-frontend modules
and high-level optimizations that require frontend cooperation.
I just think that intersects nicely here because non-GPU frontends
can be thought of not cooperating with convergence analysis, and so
their output just needs to be treated conservatively in contexts
that do honor convergence.

John.