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

[Sameer Sahasrabuddhe]

On 1/9/2015 4:14 AM, Chandler Carruth wrote:
> On Wed, Jan 7, 2015 at 8:03 PM, Sahasrabuddhe, Sameer 
> <sameer.sahasrabuddhe at amd.com <mailto: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.

So I see the following large chunks of work that are difficult to isolate:

 1. Modifying the bitcode and assembly readers and writers.
 2. Updating Clang (simultaneously?) to generate the new kind of IR with
    symbol/number mappings.
 3. Updating language bindings to deal with the new IR.

As far as I can see, the following can be decoupled from the above, but 
they are closely tied to each other:

 4. Implementing uniqued opaque strings in the most desirable way, and
    using it for the in-memory format.
 5. Creating an interface to convert the opaque symbols into suitable
    target-specific DAG nodes.

All this work, just to ensure readability in the LLVM text format. I am 
not entirely convinced that it is worth it, when opaque integers can get 
the job done just like address spaces ... are you?

>     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?

Sorry, that was just me being lazy and not reading up on the 
SelectionDAG. I expect that we will translate the the symbols into 
integer TargetConstant SDNodes ... do you see the need to be more 
flexible than that?

Sameer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150109/b3722ee9/attachment.html>