llvm dev - Jan 2015 - [LLVMdev] [RFC][PATCH][OPENCL] synchronization scopes redux

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>

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>

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>