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

[Sahasrabuddhe, Sameer]

On 1/7/2015 9:42 AM, Chandler Carruth wrote:
> I think it is significantly more friendly (and easier to debug 
> mistakes) if the textual IR uses human readable names. We already have 
> a hard time due to the totally opaque nature of address spaces -- 
> there are magical address spaces for segment stuff in x86.
>
> The strings are only opaque to the target-independent optimizer. While 
> integers and strings are equally friendly to the code in the target, 
> strings are significantly more friendly to humans reading the IR.
>
> The other advantage is that it makes it much harder to accidentally 
> write code that relies on the particular values for the integers. =]

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? But how does this work in the SelectionDAG? Also, what 
will this look like in TableGen files?

Sameer.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150108/9751708a/attachment.html>