[PATCH] D21723: [RFC] Enhance synchscope representation

[Mehdi AMINI via Phabricator via llvm-commits]

mehdi_amini added inline comments.


================
Comment at: docs/LangRef.rst:2173
+example, OpenCL supports separate memory scopes for device, work-group and
+sub-group).
+
----------------
t-tye wrote:
> kzhuravl wrote:
> > mehdi_amini wrote:
> > > I'm not convinced by the wording `it is target defined how ``<n>`` affects which other operations`, it can be read that even with the same scope it is still target define, which is not the intent right?
> > > 
> > > Straw man alternative:
> > > 
> > > ```
> > > If an atomic operation is marked ``syncscope(<n>)``, then it *synchronizes with*,
> > > and participates in the seq\_cst total orderings of, other operations
> > > running in the same scope. It is target defined how it interacts with operations
> > > in a different scope.
> > > ```
> > > 
> > Yes, you are right. I have updated the wording.
> In OpenCL, memory scopes define scope "levels" which correspond to how threads are grouped for execution. For example, a set of threads that belong to the same work-group, and specify the "workgroup" scope, only synchronize with threads in the same work-group instance. Threads in a different work-group instance do not synchronize even if they specify the "workgroup" scope.
> 
> So in general, if the scopes are target specific, it is also target specific how the the threads are grouped, and how scopes are related (for example inclusive).
> 
> I was also curious what the definition of singlethread is. My understanding was that synchronization only happens between atomic operations. So does both the signal handler and the non-signal handler code have to have atomic operations using singlethread? If used in a fence, what atomic operations pair with the fence to create the synchronizes-with relation? Generally non-atomic operations would not pair. The wording seems to imply a singlethread atomic is synchronizing with any operations in the same thread, and is presumably using thread to mean OS thread, rather than memory model notion of thread of execution which would have the signal handler and non signal handler code execution in different threads.
> 
> Since this text is fairly informal, how correct does it need to be?
So labelling an atomic operation with a syncscope named "workgroup" would not be correct according to the definition above:

`````If an atomic operation is marked ``syncscope("<a>")``, where ``<a>`` is target specific synchronization scope, then it *synchronizes with*, and participates in the seq\_cst total orderings of, other atomic operations marked ``syncscope("<a>")`````

That seems like an issue to me.



https://reviews.llvm.org/D21723