On Fri, May 6, 2016 at 4:20 PM, Matt Arsenault via cfe-commits < cfe-commits@lists.llvm.org> wrote:
> On 05/06/2016 02:42 PM, David Majnemer via cfe-commits wrote: > >> This example looks wrong to me. It doesn't seem meaningful for a function >> to be both readonly and convergent, because convergent means the call has >> some side-effect visible to other threads and readonly means the call has >> no side-effects visible outside the function. >> > This s not correct. It is valid for convergent operations to be > readonly/readnone. Barriers are a common case which do have side effects, > but there are also classes of GPU instructions which do not access memory > and still need the convergent semantics. > Can you give an example? It's not clear to me how a function could be both convergent and satisfy the readnone requirement that it not "access[...] any mutable state (e.g. memory, control registers, etc) visible to caller functions". Synchronizing with other threads seems like it would cause such a state change in an abstract sense. Is the critical distinction here that the state mutation is visible to the code that spawned the gang of threads, but not to other threads within the gang? (This seems like a bug in the definition of readonly if so, because it means that a readonly call whose result is unused cannot be deleted.) I care about this because Clang maps __attribute__((pure)) to LLVM readonly, and -- irrespective of the LLVM semantics -- a call to a function marked pure is permitted to be deleted if the return value is unused, or to have multiple calls CSE'd. As a result, inside Clang, we use that attribute to determine whether an expression has side effects, and Clang's reasoning about these things may also lead to miscompiles if a call to a function marked __attribute__((pure, convergent)) actually can have a side effect.
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
