[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