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

Sameer Sahasrabuddhe sameer.sahasrabuddhe at amd.com
Wed Jan 14 00:00:56 PST 2015


On 1/14/2015 12:51 PM, Chandler Carruth wrote:
>
> On Tue, Jan 13, 2015 at 10:42 PM, Sameer Sahasrabuddhe 
> <sameer.sahasrabuddhe at amd.com <mailto:sameer.sahasrabuddhe at amd.com>> 
> wrote:
>
>     On 1/14/2015 12:03 PM, Chandler Carruth wrote:
>>     My understanding is that there is much less of this. I also
>>     wasn't heavily involved in the address space design, and that
>>     design also has to cope with more entrenched legacy in other
>>     systems and interfaces. Not sure how much it makes sense to base
>>     the design on that.
>
>
>     I do see your ponit, though. But now the task got much bigger and
>     will have to reexamine the time required. I suppose it starts with
>     bitcode reader that can interpret existing bitcode files and
>     translate the scopes to symbols instead.
>
>
> I"m sympathetic here. We really should have an easy way of encoding 
> this kind of thing. You might be able to use "metadata" in the same 
> way that @llvm.read_register does, where it is not really metadata in 
> the traditional sense and can't be "stripped" or "discarded" in any 
> way. As I wrote in my email, I think this should be replaced by 
> something which more formally models this idea, but I don't think this 
> work should be held hostage waiting for that better system to arrive. 
> However, I also don't think this better system of synthetic constant 
> strings is very hard to build if your interested, and it would serve a 
> lot of use cases outside of synchronization scopes.

That makes sense. I will start with what's currently available. As far 
as a better string is concerned, scopes will be yet another misuse of 
metadata to be fixed in that separate project.

Sameer.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150114/29f06b33/attachment.html>


More information about the llvm-dev mailing list