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

[Chandler Carruth]

On Tue, Jan 13, 2015 at 10:42 PM, Sameer Sahasrabuddhe <
sameer.sahasrabuddhe at amd.com> wrote:

> On 1/14/2015 12:03 PM, Chandler Carruth wrote:
>
>
> 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.
>
>
> All that is true about address spaces too. On some platforms, address
> spaces could have a subset relationship, but it would be wrong to infer
> that from the numerical value. Isn't it enough to say that the number is
> opaque and should not be interpreted via any comparison?
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150113/309d3561/attachment.html>