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

[Sameer Sahasrabuddhe]

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>