[LLVMdev] LLVM Loop Vectorizer

[Hal Finkel]

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