[LLVMdev] LLVM Loop Vectorizer

[Ramanarayanan, Ramshankar]

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

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