[LLVMdev] LLVM Loop Vectorizer

Fri Oct 5 11:32:33 PDT 2012

----- Original Message -----
> From: "Ramshankar Ramanarayanan" <Ramshankar.Ramanarayanan at amd.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "llvmdev at cs.uiuc.edu Mailing List" <llvmdev at cs.uiuc.edu>, "Dibyendu Das" <Dibyendu.Das at amd.com>
> Sent: Friday, October 5, 2012 11:42:48 AM
> Subject: RE: [LLVMdev] LLVM Loop Vectorizer
> 
> If -simd option is specified opt could do validity checks, dependency
> analysis and such and recognize that a loop can be executed in
> parallel and as the -simd option is specified, convert the data
> types to vector instructions and add the scaling factor to the
> loop's iterators. Following this there can be an early machine
> function pass that sets up processor specific value in all of
> instructions in a loop vectorized by opt. This pass could look over
> options to see what is expected by the user and what is set to
> default etc.

Do you mean having this later pass choose the blocking factors, etc?

> for example for newest x86-64 there is an option
> -mprefer-avx128 for gcc, which helps over 256AVX for several cases.
> The generic vector types in llvm could be put to use in opt.

I think that, where possible, the idea is to retain the use of the generic LLVM vector types. Target-specific knowledge, however, might be used to decide when to form those types and with what operations to use them.

 -Hal

> 
> -----Original Message-----
> From: Hal Finkel [mailto:hfinkel at anl.gov]
> Sent: Friday, October 05, 2012 9:39 PM
> To: Ramanarayanan, Ramshankar
> Cc: llvmdev at cs.uiuc.edu Mailing List; Das, Dibyendu
> Subject: Re: [LLVMdev] LLVM Loop Vectorizer
> 
> 
> 
> ----- Original Message -----
> > From: "Ramshankar Ramanarayanan" <Ramshankar.Ramanarayanan at amd.com>
> > To: "Hal Finkel" <hfinkel at anl.gov>, "Dibyendu Das"
> > <Dibyendu.Das at amd.com>
> > Cc: "llvmdev at cs.uiuc.edu Mailing List" <llvmdev at cs.uiuc.edu>
> > Sent: Friday, October 5, 2012 11:00:39 AM
> > Subject: RE: [LLVMdev] LLVM Loop Vectorizer
> > 
> > Perhaps we can parameterize the size of the vector while
> > vectorizing @
> > llvm and fix up the loop iterators in a target specific pass.
> 
> I don't understand the motivation for your suggestion. Can you please
> explain?
> 
> Thanks again,
> Hal
> 
> > 
> > -----Original Message-----
> > From: llvmdev-bounces at cs.uiuc.edu
> > [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Hal Finkel
> > Sent: Friday, October 05, 2012 8:30 PM
> > To: Das, Dibyendu
> > Cc: llvmdev at cs.uiuc.edu Mailing List
> > Subject: Re: [LLVMdev] LLVM Loop Vectorizer
> > 
> > ----- Original Message -----
> > > From: "Dibyendu Das" <Dibyendu.Das at amd.com>
> > > To: "Nadav Rotem" <nrotem at apple.com>, "llvmdev at cs.uiuc.edu
> > > Mailing
> > > List" <llvmdev at cs.uiuc.edu>
> > > Sent: Friday, October 5, 2012 3:59:56 AM
> > > Subject: Re: [LLVMdev] LLVM Loop Vectorizer
> > > 
> > > I think we should try to abstract the costs of instructions of
> > > various targets instead of trying to replicate them exactly. The
> > > coarser the costing infrastructure the more robust will be the
> > > vectorization pass.
> > > Also this eliminates/reduces the need of updating the costing
> > > infrastructure as and when new h/w reduces the
> > > cost(s) of existing instructions.
> > 
> > I think that one of the big questions is where this information,
> > abstract or not, resides. The cost information needs to be abstract
> > in
> > some sense: IR instructions don't always map directly onto machine
> > instructions, we don't yet have real register-pressure information,
> > etc. Other information is more direct: does the target support
> > vectors
> > of given types, sizes, and are certain operations provided. As much
> > as
> > possible, I believe this information should be derived
> > automatically
> > from the Target TableGen files, and the pre-existing logic in
> > *ISelLowering.cpp. This requires linking those files with the
> > mid-level optimizers.
> > 
> >  -Hal
> > 
> > > - Dibyendu
> > > 
> > > -----Original Message-----
> > > From: llvmdev-bounces at cs.uiuc.edu
> > > [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Nadav Rotem
> > > Sent: Friday, October 05, 2012 11:45 AM
> > > To: llvmdev at cs.uiuc.edu Mailing List
> > > Subject: [LLVMdev] LLVM Loop Vectorizer
> > > 
> > > Hi,
> > > 
> > > We are starting to work on an LLVM loop vectorizer. There's
> > > number
> > > of different projects that already vectorize LLVM IR. For example
> > > Hal's BB-Vectorizer, Intel's OpenCL Vectorizer, Polly, ISPC,
> > > AnySL,
> > > just to name a few. I think that it would be great if we could
> > > collaborate on the areas that are shared between the different
> > > projects. I think that refactoring LLVM in away that would expose
> > > target information to IR-level transformations would be a good
> > > way
> > > to start. Vectorizers, as well as other IR-level transformations,
> > > require target-specific information, such as the cost of
> > > different
> > > instruction or the availability of certain features. Currently,
> > > llvm-based vectorizers do not make use of this information, or
> > > just
> > > hard-code target information. A loop vectorizer would need target
> > > information. After we have some basic target information
> > > infrastructure in place we can start discussing the vectorizer
> > > itself.
> > > 
> > > I think that the first step would be to expose Target Lowering
> > > Interface (TLI) to OPT's IR-level passes. Currently TLI is only
> > > available in LLC. I suggest that we merge LLC and OPT into a
> > > single
> > > tool that will drive both IR-level passes and the codegen. LLC
> > > and
> > > OPT can remain as wrappers around the new tool. Please let me
> > > know
> > > if you can think of a good name for the new tool. I was thinking
> > > that "llvm-cli" may be a good name (cli = command line
> > > interface).
> > > OPT and LLC are only used by LLVM developers, so the impact of
> > > this
> > > change on the user community would be small.
> > > 
> > > Thanks,
> > > Nadav
> > > _______________________________________________
> > > 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
> > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> > > 
> > 
> > --
> > Hal Finkel
> > Postdoctoral Appointee
> > Leadership Computing Facility
> > Argonne National Laboratory
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> > 
> > 
> > 
> 
> --
> Hal Finkel
> Postdoctoral Appointee
> Leadership Computing Facility
> Argonne National Laboratory
> 
> 

-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory