search for: minimum_dependency_distance

...but we've not really thought about it yet. Regarding the proposal, I'm in favor. I don't like using the name 'savelen' however. I can forgive OpenMP for choosing such a short name because people need to type it, but I'd prefer that the metadata have a more-descriptive name. minimum_dependency_distance is perhaps better. -Hal > > Can we translate llvm.mem.vectorize.safelen into an invariant on k > similarly as to what you're proposing that the programmer should > ensure? > > Cheers, > Roel > > [0] http://comments.gmane.org/gmane.comp.compilers.llvm.devel/749...

...idth so that some processing infrastructure can be shared easily. > I don't like using the name 'safelen' however. I can forgive OpenMP > for choosing such a short name because people need to type it, > but I'd prefer that the metadata have a more-descriptive name. > minimum_dependency_distance is perhaps better. I'm open to naming suggestions, though I'm wondering if sticking with what is now a term of art in OpenMP might be the least of all evils, because the semantics turn out to be a little more subtle than just a minimum dependence distance. My current wording of the seman...

...e.width so that some processing infrastructure can be shared easily. > I don't like using the name 'safelen' however. I can forgive OpenMP > for choosing such a short name because people need to type it, > but I'd prefer that the metadata have a more-descriptive name. > minimum_dependency_distance is perhaps better. I'm open to naming suggestions, though I'm wondering if sticking with what is now a term of art in OpenMP might be the least of all evils, because the semantics turn out to be a little more subtle than just a minimum dependence distance. My current wording of the semant...

...cessing infrastructure can be shared easily. > > > I don't like using the name 'safelen' however. I can forgive OpenMP > > for choosing such a short name because people need to type it, > > but I'd prefer that the metadata have a more-descriptive name. > > minimum_dependency_distance is perhaps better. > > I'm open to naming suggestions, though I'm wondering if sticking with > what is now a term of art in OpenMP might be the least of all evils, > because the semantics turn out to be a little more subtle than > just a minimum dependence distance. My curre...

...n be shared easily. > > > > > I don't like using the name 'safelen' however. I can forgive OpenMP > > > for choosing such a short name because people need to type it, > > > but I'd prefer that the metadata have a more-descriptive name. > > > minimum_dependency_distance is perhaps better. > > > > I'm open to naming suggestions, though I'm wondering if sticking with > > what is now a term of art in OpenMP might be the least of all evils, > > because the semantics turn out to be a little more subtle than > > just a minimum depen...

...n be shared easily. > > > >> I don't like using the name 'safelen' however. I can forgive OpenMP > >> for choosing such a short name because people need to type it, > >> but I'd prefer that the metadata have a more-descriptive name. > >> minimum_dependency_distance is perhaps better. > > > > I'm open to naming suggestions, though I'm wondering if sticking with > > what is now a term of art in OpenMP might be the least of all evils, > > because the semantics turn out to be a little more subtle than > > just a minimum dep...

...> > > > > > I don't like using the name 'safelen' however. I can forgive OpenMP > > > > for choosing such a short name because people need to type it, > > > > but I'd prefer that the metadata have a more-descriptive name. > > > > minimum_dependency_distance is perhaps better. > > > > > > I'm open to naming suggestions, though I'm wondering if sticking with > > > what is now a term of art in OpenMP might be the least of all evils, > > > because the semantics turn out to be a little more subtle than > >...

Julia and OpenMP 4.0 have features where the user can bless a loop as having no memory dependences that prevent vectorization, thus enabling vectorization of loops not amenable to compile-time or run-time dependence analysis. LLVM currently has no metadata to express such, as explained further below. I'd like to propose new metadata that enables front-ends to tell the vectorizer that