While we're planning to fix the convergent definition in D68994, I thought
this would be an opportunity to fix another design flaw in the convergent
attribute.
Invert the direction of the convergent attribute by removing it, and
adding the noconvergent attribute. The current convergent attribute is
currently odd, as adding it is required for correctness. There is a
burden on frontends in environments that care about convergent
operations to add the attribute just in case it is needed. This has
proven to be somewhat problematic, and different frontend projects
have consistently run into problems related to this. OpenMP and SYCL
for example are currently not assuming convergent by default.
The backwards definition also did not provide a way to directly
specify non-convergent functions in some cases. There is no way to
specify a negative attribute, so when convergent needs to be assumed,
there was no way to opt-out. By inverting this, user attribute usage
is more flexible.
Assume the old convergent semantics by default, so an undecorated
function is correct with respect to convergence. For compatbility
purposes, the old attribute can simply be ignored. The new
noconvergent attribute produces the old default behavior.
Infer the noconvergent attribute, which is similar to nounwind.
The main risk of this change is negative tests in control flow
passes. They may no longer trigger due to not having noconvergent, and
not for what they truly intended to test. I've speculatively added
noconvergent to JumpThreading tests and a handful of others, but other
passes may be relevant.
For now this is just trying to change the IR attribute handling. The
MachineInstr flag and intrinsic decoration are still in the positive
direction. IntrConvergent should probably be inverted, but I think
having the MI flag be positive is probably fine.
The source language attribute for convergent is now a no-op. It could
arguably try to enable convergence in a non-SPMD language, but using
this would probably be very error prone. A user facing noconvergent
attribute is probably the next step.
I don't think GPU thread convergence is a concept that could ever really be applied to a program containing ObjC exceptions, so while this seems correct, it also seems pointless.