[LLVMdev] [PATCH] parallel loop awareness to the LoopVectorizer
hfinkel at anl.gov
Mon Jan 28 08:51:25 PST 2013
----- Original Message -----
> From: "Nadav Rotem" <nrotem at apple.com>
> To: "Pekka Jääskeläinen" <pekka.jaaskelainen at tut.fi>
> Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
> Sent: Monday, January 28, 2013 10:45:36 AM
> Subject: Re: [LLVMdev] [PATCH] parallel loop awareness to the LoopVectorizer
> Hi Pekka,
> I am okay with this patch, assuming that you follow the review of
> Tobias and Renato and provide a separate patch for the
> min-iter-count and a few test cases.
> I think that it would be a good idea to start a new thread and to
> discuss the best way to annotate loops in LLVM.
Is this sufficient to implement #pragma ivdep in clang?
> On Jan 28, 2013, at 5:49 AM, Pekka Jääskeläinen
> <pekka.jaaskelainen at tut.fi> wrote:
> > Hi Renato,
> > On 01/28/2013 03:22 PM, Renato Golin wrote:
> >> This seems an awfully specific check on a generic part of the
> >> code... If
> > True. Perhaps the check is better encapsulated, e.g., in the Loop
> > class?
> > Or, if there's such thing as a loop-carried data dependency
> > analyzer,
> > the correct place could be there, as a trivial "no deps" analysis.
> > > this metadata standard in any form? If this OpenCL specific? Does
> > > all
> > This metadata is not standard in any form. Therefore the request
> > for comments. However, its meaning is generic, not OpenCL
> > specific at all. It specifies that the loop iterations can be
> > treated as independent, regardless of the memory operations the
> > body contains. Thus, the potential cross-iteration memory
> > dependencies
> > can be considered a programming error.
> > > OpenCL front-ends generate the same meta-data in that way? Etc...
> > I have no knowledge of other OpenCL implementations than
> > pocl as I haven't seen their code.
> >> It also converts the "min iteration count to vectorize" to a
> >> parameter so
> >> this can be controlled from the command line.
> >> Is this really necessary? Do you have use cases where this would
> >> make sense?
> > Where a lower threshold could be useful? At least with loops having
> > long
> > bodies and loops with outer loops that iterate the inner loop many
> > times.
> > In fact, shouldn't the default minimum be the minimum vector width
> > of the
> > machine? The cost estimation routine should take care of the actual
> > profitability estimate?
> >> I think you should send a test case with this patch, not separate.
> > As soon as there's a consensus on the metadata format and where
> > the check shall reside in, I'll prepare a proper patch with
> > a vectorizer test case.
> > Thanks for the comments so far,
> > --
> > Pekka
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev