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

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>

Ping! We need to close on whether everyone is convinced that symbolic 
memory scopes have a significant advantage over opaque numbers. Either 
of them will be examined by optimizations using a target-implemented 
API. I personally don't think that readability in the LLVM text format 
is worth the effort, especially given that address spaces work well 
enough with opaque numbers.

Sameer.

On 1/9/2015 10:18 AM, Sameer Sahasrabuddhe wrote:
>
> 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/20150114/ee2ad0ed/attachment.html>

On Tue, Jan 13, 2015 at 10:27 PM, Sameer Sahasrabuddhe <
sameer.sahasrabuddhe at amd.com> wrote:
> Ping! We need to close on whether everyone is convinced that symbolic
> memory scopes have a significant advantage over opaque numbers. Either of
> them will be examined by optimizations using a target-implemented API. I
> personally don't think that readability in the LLVM text format is
worth
> the effort, especially given that address spaces work well enough with
> opaque numbers.

I am much more comfortable with symbolic memory scopes. The reason I feel
this way is actually because there *is* a particular ordering of them that
the target will mandate. Having an ordering but having it *not* be the
order of the numbers used seems too actively confusing to me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150113/c796958b/attachment.html>