On 01/29/2013 08:22 PM, Dan Gohman wrote:> "Ignore assumed dependencies" is shaky semantics. I haven't seen anything > explicitly spell out which dependencies a compiler is guaranteed to detect. > How can users use such a directive safely in a loop which has dependencies? > I understand that this is what icc's documentation says, but I'm wondering > if there's a real motivation for this design other than blind compatibility.I agree. I was puzzled by it myself until I ended up concluding that if the set of required analysis is not defined it can be an empty set, thus equivalent to "no dep checking at all needed": http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-January/058727.html Maybe the safe thing here is to rename it back to the honest "llvm.loop.parallel" or similar and we can add a separate one for the assumed_dep later on. This one would support the truly parallel loops (at least OpenMP for and OpenCL WIloops) where no compiler checking at all can be assumed by the programmer. Any objections? Paul Redmond? -- --Pekka
----- Original Message -----> From: "Pekka Jääskeläinen" <pekka.jaaskelainen at tut.fi> > To: "Dan Gohman" <dan433584 at gmail.com> > Cc: "CVS Commit Messages for LLVM repository" <llvm-commits at cs.uiuc.edu>, "LLVM Developers Mailing List" > <llvmdev at cs.uiuc.edu> > Sent: Tuesday, January 29, 2013 1:42:27 PM > Subject: Re: [PATCH] parallel loop metadata > > On 01/29/2013 08:22 PM, Dan Gohman wrote: > > "Ignore assumed dependencies" is shaky semantics. I haven't seen > > anything > > explicitly spell out which dependencies a compiler is guaranteed to > > detect. > > How can users use such a directive safely in a loop which has > > dependencies? > > I understand that this is what icc's documentation says, but I'm > > wondering > > if there's a real motivation for this design other than blind > > compatibility. > > I agree. I was puzzled by it myself until I ended up concluding that > if the set of required analysis is not defined it can be an empty > set, > thus equivalent to "no dep checking at all needed": > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-January/058727.html > > Maybe the safe thing here is to rename it back to the honest > "llvm.loop.parallel" or similar and we can add a separate one for > the assumed_dep later on. This one would support the truly parallel > loops (at least OpenMP for and OpenCL WIloops) where no compiler > checking at all can be assumed by the programmer.Will parallel always be synonymous with no_interiteration_dependencies? I'm sightly worried that 'parallel' seems too much like a directive, and we may want it to mean something else in the future. -Hal> > Any objections? Paul Redmond? > > -- > --Pekka > > _______________________________________________ > llvm-commits mailing list > llvm-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits >
On 01/29/2013 10:17 PM, Hal Finkel wrote:> Will parallel always be synonymous with no_interiteration_dependencies? I'm > sightly worried that 'parallel' seems too much like a directive, and we may > want it to mean something else in the future.I think the semantics of a "parallel loop" is: If my loop, I hereby state as "parallel", has loop-carried dependencies, I have made a programming mistake and you, the compiler, are free to punish me by producing undefined results. We can add other metadata later on. E.g. "ivdep": My loop might have some dependencies I know you know about, and also some dependencies which are impossible (for you!) to analyze. The latter ones you can ignore as I know those are not real dependencies, but please do not ignore those I know you know about :) I think the actual "strong" parallel loop semantics is more interesting as it gives the most freedom and is not even a bit vague. -- --Pekka
Hi Pekka, On 2013-01-29, at 2:42 PM, Pekka Jääskeläinen wrote:> Maybe the safe thing here is to rename it back to the honest > "llvm.loop.parallel" or similar and we can add a separate one for > the assumed_dep later on. This one would support the truly parallel > loops (at least OpenMP for and OpenCL WIloops) where no compiler > checking at all can be assumed by the programmer. > > Any objections? Paul Redmond? >I don't have any objections. I think the only requirement is that the semantics are clearly defined. Personally I think this metadata should be used to guide the vectorizer only. I'm not sure how it will be used in the context of OpenMP or OpenCL. For OpenMP I assume you'd add this metadata to parallel_for loops. At what point do you insert the runtime calls? Does LLVM need to know how to target each runtime? paul> -- > --Pekka > > _______________________________________________ > llvm-commits mailing list > llvm-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
----- Original Message -----> From: "Paul Redmond" <paul.redmond at intel.com> > To: "Pekka Jääskeläinen" <pekka.jaaskelainen at tut.fi> > Cc: "CVS Commit Messages for LLVM repository" <llvm-commits at cs.uiuc.edu>, "LLVM Developers Mailing List" > <llvmdev at cs.uiuc.edu> > Sent: Tuesday, January 29, 2013 3:27:03 PM > Subject: Re: [PATCH] parallel loop metadata > > Hi Pekka, > > On 2013-01-29, at 2:42 PM, Pekka Jääskeläinen wrote: > > > Maybe the safe thing here is to rename it back to the honest > > "llvm.loop.parallel" or similar and we can add a separate one for > > the assumed_dep later on. This one would support the truly parallel > > loops (at least OpenMP for and OpenCL WIloops) where no compiler > > checking at all can be assumed by the programmer. > > > > Any objections? Paul Redmond? > > > > I don't have any objections. I think the only requirement is that the > semantics are clearly defined. > > Personally I think this metadata should be used to guide the > vectorizer only. I'm not sure how it will be used in the context of > OpenMP or OpenCL. For OpenMP I assume you'd add this metadata to > parallel_for loops. At what point do you insert the runtime calls? > Does LLVM need to know how to target each runtime?I think that the general direction being pursued for OpenMP is to do frontend lowering (outlining). However, we'd still want iteration-independence metadata to attach to the outlined loop bodies. -Hal> > paul > > > -- > > --Pekka > > > > _______________________________________________ > > llvm-commits mailing list > > llvm-commits at cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits > > > _______________________________________________ > llvm-commits mailing list > llvm-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits >
Hi, In a personal capacity I'm quite interested in the issues of producing from a high-level language some LLVM IR which is labelled with vectorization info (including potentially actually reordering data in memory). | I don't have any objections. I think the only requirement is that the semantics are clearly defined. I think that's very important :-) | Personally I think this metadata should be used to guide the vectorizer only. I'm not sure how it will be used in the context of OpenMP or OpenCL. For OpenMP I assume you'd add this metadata to | parallel_for loops. At what point do you insert the runtime calls? Does LLVM need to know how to target each runtime? I think there's two use cases: where a human programmer has written an annotation (in some source language variant) where it represents a "best guess" which the compiler might decide is suboptimal and choose a variant of its own, and when the metadata has been added by a front-end compiler -- either to empirically observer the effect or because it's part of some more extensive performance directed code-reorganisation done by the front-end -- where it really ought to be "obeyed unless impossible". In particular, the LLVM backend is designed to be usable in routine production, which means that certain kinds of very expensive performance optimization will be unfeasible to be integrated. So I'd like at least a way to say "this is what I _really_ want the vectorizer to assume" in such metadata. Regards, Dave -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.