[LLVMdev] Proposal for ""llvm.mem.vectorize.safelen"

[Hal Finkel]

----- 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