----- Original Message -----> From: "Roel Jordans" <r.jordans at tue.nl> > To: llvmdev at cs.uiuc.edu > Sent: Wednesday, August 13, 2014 5:57:15 AM > Subject: Re: [LLVMdev] Proposal for ""llvm.mem.vectorize.safelen" > > > > > WHY CURRENT METADATA DOES NOT SUFFICE > > ------------------------------------- > > > > There are currently two pieces of metadata that come close, but > > miss the > > desired semantics. > > > > * llvm.loop.vectorize.width - hints at what vectorization width to > > use > > *if* the loop is safe to vectorize. It does not specify that > > the > > loop is safe to vectorize. > > > > * llvm.mem.parallel_loop_access - indicates that accesses do not > > have a loop-carried dependence between them. That's too broad a > > brush, as it precludes loops that do have dependences (e.g. > > "forward > > lexical dependences") that are nonetheless vectorizable. > > > > How does this relate to the recent additions by Hal on invariants > using > llvm.assume? [0]I don't think this related because the assumptions don't provide any direct way of asserting things about memory aliasing. That might be an interesting thing to do, 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/74941 > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
----- Original Message -----> From: "Hal Finkel" <hfinkel at anl.gov> > To: "Roel Jordans" <r.jordans at tue.nl> > Cc: llvmdev at cs.uiuc.edu > Sent: Tuesday, August 19, 2014 5:57:54 PM > Subject: Re: [LLVMdev] Proposal for ""llvm.mem.vectorize.safelen" > > ----- Original Message ----- > > From: "Roel Jordans" <r.jordans at tue.nl> > > To: llvmdev at cs.uiuc.edu > > Sent: Wednesday, August 13, 2014 5:57:15 AM > > Subject: Re: [LLVMdev] Proposal for ""llvm.mem.vectorize.safelen" > > > > > > > > WHY CURRENT METADATA DOES NOT SUFFICE > > > ------------------------------------- > > > > > > There are currently two pieces of metadata that come close, but > > > miss the > > > desired semantics. > > > > > > * llvm.loop.vectorize.width - hints at what vectorization width > > > to > > > use > > > *if* the loop is safe to vectorize. It does not specify that > > > the > > > loop is safe to vectorize. > > > > > > * llvm.mem.parallel_loop_access - indicates that accesses do not > > > have a loop-carried dependence between them. That's too broad > > > a > > > brush, as it precludes loops that do have dependences (e.g. > > > "forward > > > lexical dependences") that are nonetheless vectorizable. > > > > > > > How does this relate to the recent additions by Hal on invariants > > using > > llvm.assume? [0] > > I don't think this related because the assumptions don't provide any > direct way of asserting things about memory aliasing. That might be > an interesting thing to do, 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.Also, looking at the original proposal again, I see no reason to restrict this to an i32: we might as well allow it to be an i64 obviously we don't have billion-lane vectors, but the metadata can also be useful for other kinds of analysis). I recommend that you send patches for an implementation (including the Loop::GetAnnotatedVectorSafelen function and associated updates to the vectorizer) for review. Make sure to remember LangRef updates! -Hal> > -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/74941 > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > -- > Hal Finkel > Assistant Computational Scientist > Leadership Computing Facility > Argonne National Laboratory >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
> I recommend that you send patches for an implementation > (including the Loop::GetAnnotatedVectorSafelen function > and associated updates to the vectorizer) for review.I expect to send the patches for review later this week.> Make sure to remember LangRef updates!Thanks for the reminder.> Also, looking at the original proposal again, I see no reason > to restrict this to an i32: we might as well allow it to be an > i64 obviously we don't have billion-lane vectors, but the > metadata can also be useful for other kinds of analysis).I doubt there is much advantage between knowing the minimum loop-carried dependence difference is 1u<<31 or 1u<<63. Unless there is a clear need for the higher values less than infinity, It would seem simpler for now to adopt the same conventions as llvm.loop.vectorize.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 semantics for safelen of k are: /// The loop can be assumed to have no loop-carried /// lexically backward dependencies with distance less than k. - Arch D. Robison Intel Corporation