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.
Thank you all for comments, On 01/30/2013 11:22 AM, David Tweed wrote:> 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 :-)...> 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.I agree. Thus, let's start with the 'parallel' semantics first, not the vague ones. A conclusion of some kind for me to update the patch: 1) Rename the loop branch metadata back to llvm.loop.parallel. I'll add a definition of its semantics (as comments to Loop::isParallel()): No loop-carried dependency checking at all can be assumed with this type of loops. If the compiler does some analysis to improve the performance or other reasons, it still can, but is not required to do so. 2) Keep the memory accessing instruction metadata as it is. At least until something better appears. The rationale is that when the parallel loop is marked this way (both a branch metadata and memory instruction metadata required for isParallel()), missing metadata in some of the memory instructions due to some optimizations that do not propagate the data correctly does not cause breakage (lead to assuming a now-sequential loop is still parallel). It just potentially makes the parallel loop non-parallel which should be safe. In addition, the scheme of augmenting memory accesses with parallelism info can be extended to retain the parallelism data over loop unrolling too (useful for instruction scheduling). Also, e.g., retaining the restricted pointer data across function inlining might be able to use a similar mechanism. We can improve the actual marking mechanism gradually because the parallelism check will be wrapped inside Loop::isParallel(). Is this OK? -- --Pekka
On Wed, Jan 30, 2013 at 12:35 PM, Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi> wrote:> Thank you all for comments, > > > On 01/30/2013 11:22 AM, David Tweed wrote: >> >> 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 :-) > > ... > >> 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. > > > I agree. Thus, let's start with the 'parallel' semantics first, not > the vague ones. > > A conclusion of some kind for me to update the patch: > > 1) Rename the loop branch metadata back to llvm.loop.parallel. > > I'll add a definition of its semantics (as comments to Loop::isParallel()):Hello Pekka, I think it would be better to add a section to the LangRef: http://llvm.org/docs/LangRef.html#metadata A good comment would be helpful, too, but LangRef should be normative. Dmitri -- main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/