On Dec 26, 2013, at 10:38 PM, Andrew Trick <atrick at apple.com> wrote:>> >> >> I think "memfence" could be an issue if we use the attribute to summarize LLVM atomic load/store and fence instructions (in addition to OpenCL barriers). >> >> I have no idea what semantics you would attach to it in this case. I've not seen any clear explanation of such semantics yet in this thread. >> >> The only clear semantics I've seen expressed so far seem much more appropriate for attaching to a noduplicate call to an intrinsic... But I think I'll need to read this thread again to re-absorb much of the information after the holidays. =] > > I think it would be too misleading and bizarre to define a memfence/nomemfence attribute that does not relate to memory fence instructions. In the future, I do see a potential use for such an attribute, but that discussion belongs in a different thread and would be premature (we would have to talk about alias info on calls).I’m not sure what you mean by this. I was never thinking the fence instruction was detached from this, and it would just imply the parent function has a memfence. I don’t see the use of another memfence attribute that would not do this.> > Let’s say we’re just talking about llvm.opencl.memfence(addressspace) then. The same argument about attribute propagation applies, though I will defer those who are trying to make opencl correct. > > -Andy >So the plan is have a nomemfence(N) attribute that indicates there is no memfence for addrspace(N) on a function, and can be specified 0 or more times. readonly or readnone imply nomemfence for all address spaces. Because the normal case is nomemfence for most address spaces, something else is needed to avoid needing marking every function with nomemfence(0..max address space) when only a few usually matter. I suggest module metadata named !”llvm.used_addrspaces” that will list the address spaces relevant for the module. The absence of a fence will infer nomemfence for all of these address spaces minus any found potential fences. Without the metadata, only nomemfence(0) will be inferred. For the purpose of inferring nomemfence, fence instructions will be treated as a memfence for all address spaces, as it currently does not specify one (despite the atomic instructions accepting non-zero address spaces,) Additionally, an llvm.memfence intrinsic, which will take a constant i32 parameter for the address space to be fenced. This behaves as call to a function with nomemfence set for every address space except the one specified by its constant parameter. This part might not actually be necessary (the metadata plus target intrinsics marked with whatever nomemfences are required is probably enough, but might be useful anyway). Does this sound good? -Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140103/1fd782f3/attachment.html>
On Jan 3, 2014, at 6:49 PM, Matt Arsenault <arsenm2 at gmail.com> wrote:> On Dec 26, 2013, at 10:38 PM, Andrew Trick <atrick at apple.com> wrote: >>> >>> >>> I think "memfence" could be an issue if we use the attribute to summarize LLVM atomic load/store and fence instructions (in addition to OpenCL barriers). >>> >>> I have no idea what semantics you would attach to it in this case. I've not seen any clear explanation of such semantics yet in this thread. >>> >>> The only clear semantics I've seen expressed so far seem much more appropriate for attaching to a noduplicate call to an intrinsic... But I think I'll need to read this thread again to re-absorb much of the information after the holidays. =] >> >> I think it would be too misleading and bizarre to define a memfence/nomemfence attribute that does not relate to memory fence instructions. In the future, I do see a potential use for such an attribute, but that discussion belongs in a different thread and would be premature (we would have to talk about alias info on calls). > > I’m not sure what you mean by this. I was never thinking the fence instruction was detached from this, and it would just imply the parent function has a memfence. I don’t see the use of another memfence attribute that would not do this. > > >> >> Let’s say we’re just talking about llvm.opencl.memfence(addressspace) then. The same argument about attribute propagation applies, though I will defer those who are trying to make opencl correct. >> >> -Andy >> > > So the plan is have a nomemfence(N) attribute that indicates there is no memfence for addrspace(N) on a function, and can be specified 0 or more times. readonly or readnone imply nomemfence for all address spaces.That seems conservatively correct and I agree with the readonly/readnone implication. We generally model fences as memory “writes”.> Because the normal case is nomemfence for most address spaces, something else is needed to avoid needing marking every function with nomemfence(0..max address space) when only a few usually matter. I suggest module metadata named !”llvm.used_addrspaces” that will list the address spaces relevant for the module. The absence of a fence will infer nomemfence for all of these address spaces minus any found potential fences. Without the metadata, only nomemfence(0) will be inferred.Just to be clear, only leaf functions (and functions whose callee graph is contained completely within the module) will be marked. Is it possible to indicate an unspecified address space? A nomemfence attribute with no address space would imply no fence in any address space. Would that eliminate the need for metadata?> For the purpose of inferring nomemfence, fence instructions will be treated as a memfence for all address spaces, as it currently does not specify one (despite the atomic instructions accepting non-zero address spaces,)Good. I assume any atomic load/store with ordering != unordered will be treated as a fence for it’s address space.> Additionally, an llvm.memfence intrinsic, which will take a constant i32 parameter for the address space to be fenced. This behaves as call to a function with nomemfence set for every address space except the one specified by its constant parameter. This part might not actually be necessary (the metadata plus target intrinsics marked with whatever nomemfences are required is probably enough, but might be useful anyway).Do you think such an intrinsic would be useful without target support? Do we want a software-only fence? If you want a hardware fence but want to limit it to the global address space, then maybe the fence instruction should take an address space.> Does this sound good?Overall yes. Thanks. -Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140103/2c9a9dd4/attachment.html>
On Jan 3, 2014, at 10:17 PM, Andrew Trick <atrick at apple.com> wrote:> >> Because the normal case is nomemfence for most address spaces, something else is needed to avoid needing marking every function with nomemfence(0..max address space) when only a few usually matter. I suggest module metadata named !”llvm.used_addrspaces” that will list the address spaces relevant for the module. The absence of a fence will infer nomemfence for all of these address spaces minus any found potential fences. Without the metadata, only nomemfence(0) will be inferred. > > Just to be clear, only leaf functions (and functions whose callee graph is contained completely within the module) will be marked. > > Is it possible to indicate an unspecified address space? A nomemfence attribute with no address space would imply no fence in any address space. Would that eliminate the need for metadata?That was my first idea, but I don’t remember why I rejected it originally. I think that would work instead.> Do you think such an intrinsic would be useful without target support? Do we want a software-only fence?I’m not sure. I don’t think I have much use for it.> If you want a hardware fence but want to limit it to the global address space, then maybe the fence instruction should take an address space.I think the fence instruction should take an address space, but that’s mostly a separate issue. The OpenCL mem_fence/barrier I’m trying to fix isn’t really the same as the fence instruction since it’s for all memory accesses, and not just atomics. I also need at least 6 different target intrinsics with memfences for mem_fence, barrier and all the permutations of address spaces, so a single general memfence intrinsic would be insufficient.> >> Does this sound good? > > Overall yes. Thanks. > > -Andy-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140103/f72ff75d/attachment.html>