> On Aug 21, 2016, at 8:51 PM, Sameer Sahasrabuddhe <sameer at sbuddhe.net> wrote: > > On Sun, Aug 21, 2016 at 11:49 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: >> On Aug 21, 2016, at 11:14 AM, Philip Reames <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote: >> >> Given my current time commitments, having me on the critical path for any proposal is not a good idea. I'm willing to step aside here as long as the proposal is well reviewed by someone who's familiar with the memory model. Hal, Sanjoy, JF, Chandler, and Danny would all be reasonable alternates. > > OK, good to know. I put you on the path because you wrote: > > "I am opposed to extending the instructions without a strong motivating case. I don't care anywhere near as much about metadata based schemes, but extending the instruction semantics imposes a much larger burden on the rest of the community. That burden has to be well justified and supported." > > It is not clear to me right now if the "use case" makes it "well justified" or not (an alternative being using intrinsic for OpenCL as Justin Lebar mentioned). I don’t feel I can answer this, so adding CC Chandler and Sanjoy to begin with. > > One yardstick to determine if this is "well justified" is to ask if any LLVM backend has an undefined behaviour similar to OpenCL if the scope metadata is dropped. For every LLVM target X which can be potentially targetted from OpenCL, if the metadata is dropped (in one module but not another), does the memory model for X still produce behaviour that is compatible with the behaviour intended by the original program? If that question cannot be answered satisfactorily for all cases, then metadata is not a reliable way to move forward. > > To put it differently, when viewed as an "OpenCL implementation", can every LLVM backend guarantee that when OpenCL scopes are lowered to metadata, the synchronisation specified in the original program is preserved?This does not address why you can’t use intrinsics (like the CUDA implementation does apparently). — Mehdi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160821/7fbfa16e/attachment.html>
> On Aug 21, 2016, at 8:54 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Aug 21, 2016, at 8:51 PM, Sameer Sahasrabuddhe <sameer at sbuddhe.net <mailto:sameer at sbuddhe.net>> wrote: >> >> On Sun, Aug 21, 2016 at 11:49 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: >>> On Aug 21, 2016, at 11:14 AM, Philip Reames <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote: >>> >>> Given my current time commitments, having me on the critical path for any proposal is not a good idea. I'm willing to step aside here as long as the proposal is well reviewed by someone who's familiar with the memory model. Hal, Sanjoy, JF, Chandler, and Danny would all be reasonable alternates. >> >> OK, good to know. I put you on the path because you wrote: >> >> "I am opposed to extending the instructions without a strong motivating case. I don't care anywhere near as much about metadata based schemes, but extending the instruction semantics imposes a much larger burden on the rest of the community. That burden has to be well justified and supported." >> >> It is not clear to me right now if the "use case" makes it "well justified" or not (an alternative being using intrinsic for OpenCL as Justin Lebar mentioned). I don’t feel I can answer this, so adding CC Chandler and Sanjoy to begin with. >> >> One yardstick to determine if this is "well justified" is to ask if any LLVM backend has an undefined behaviour similar to OpenCL if the scope metadata is dropped. For every LLVM target X which can be potentially targetted from OpenCL, if the metadata is dropped (in one module but not another), does the memory model for X still produce behaviour that is compatible with the behaviour intended by the original program? If that question cannot be answered satisfactorily for all cases, then metadata is not a reliable way to move forward. >> >> To put it differently, when viewed as an "OpenCL implementation", can every LLVM backend guarantee that when OpenCL scopes are lowered to metadata, the synchronisation specified in the original program is preserved? > > This does not address why you can’t use intrinsics (like the CUDA implementation does apparently).Let me rephrase: why is it preferable to add first class instruction support for opaque scope rather than using intrinsics? — Mehdi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160821/9f988a6f/attachment.html>
> Let me rephrase: why is it preferable to add first class instruction support for opaque scope rather than using intrinsics?Given that LLVM core now supports atomic instructions, it would seem desirable to use them for all languages supported by LLVM. This would allow optimizations to be aware of the memory semantics. By using intrinsics this information no longer becomes available in a unified way. It also requires the target code generator to support both the LLVM atomics as well as all the additional intrinsics. In general it seems preferable to use a single approach rather than multiple approaches to express information. Currently LLVM has support for atomics by specifying both the memory ordering and memory scope as enumerated values specified by an enum type. However, the values for memory scope currently only include those needed for CPU-style targeted languages. Languages such as CUDA and OpenCL introduce additional memory scopes into the memory model. This patch extends the existing enumeration for memory scope to allow the target to define additional memory scopes that can be used by such languages. The current bit code already represents the memory scope as a 32 bit unsigned value, so this change introduces no backward compatible issues. Thanks, -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160823/b0ea79ce/attachment.html>