[LLVMdev] [RFC][PATCH][OPENCL] synchronization scopes redux

[Chandler Carruth]

On Wed, Jan 7, 2015 at 8:03 PM, Sahasrabuddhe, Sameer <
sameer.sahasrabuddhe at amd.com> wrote:

> Here's what this looks like to me:
>
>    1. LLVM text format will use string symbols for memory scopes, and not
>    numbers. The set of strings is target defined, but "singlethread" and
>    "system" are reserved and have a well-known meaning.
>
>     2. "The keyword informally known as system" represents the set of all
>    threads that could possibly synchronize on the location being accessed
>    by the current atomic instruction. These threads could be local, remote,
>    executing on different agents, or whatever else is admissible on that
>    particular platform. We still need to agree on the keyword to be used.
>
>     3. The bitcode will store memory scopes as unsigned integers, since
>    that is the easiest way to maintain compatibility. The values 0 and 1 are
>    special. All other values are meaningful only within that bc file. The file
>    will also provide a map from unsigned integers to string symbols which
>    should be used to interpret all the non-standard integers.
>       1. The map must not include 0 and 1, since the reader will
>       internally map them to singlethread" and "system" respectively.
>       2. If the map is empty or non-existent, then all non-zero values
>       will be mapped to "system", which is the current behaviour.
>
>        4. The in-memory structure for an atomic instruction will
>    represent memory scope as a reference to a uniqued strings. This
>    eliminates any notion of performing arithmetic on the scope indicator,
>    or to write code that is sensitive to its numerical value.
>
>     5. Behaviour is undefined if a symbolic scope used in the IR is not
>    supported by the target. This is true for "singlethread" and "system" also,
>    since some targets may not have those scopes.
>
> Is this correct?
>
Generally, yes.

Regarding the specific way of using strings, see the email I just sent
about metadata being used poorly, this is a place where we might use
metadata to encode the string, or we might do something more direct as you
propose. I think it would be good to do something like what I propose in
that thread to have nicely uniqued opaque string entities in the IR, and
then use them here for marking scopes.

> But how does this work in the SelectionDAG? Also, what will this look like
> in TableGen files?
>
Not sure what you mean here? I haven't looked at implementing it, but from
the DAG down you should get to collapse this rapidly toward target-specific
nodes / structures / representations?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150108/847eab03/attachment.html>