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

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>

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 <mailto: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?

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.

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

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>

On 01/13/2015 10:33 PM, Chandler Carruth wrote:
>
> On Tue, Jan 13, 2015 at 10:27 PM, Sameer Sahasrabuddhe 
> <sameer.sahasrabuddhe at amd.com <mailto: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.
Chandler, while I agree with you, I'm not sure this should block forward 
progress.  Having the scope markers as opaque integers doesn't block us 
from later adding a side table of string names and changing the IR 
representation.  Forward serialization would be fairly straight forward 
as long as you didn't care about the resulting name.  Why don't we let 
this move forward with numeric IDs and then come back with string names 
at some point in the future?

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