[PATCH] Add a DecomposeVectors pass

[Nadav Rotem]

It looks like the alignment of load/store is not handled the right way. The vector load may have an alignment of 1 byte so using the element alignment is incorrect. The new alignment should be the min of the original alignment and the element alignment. 

Sent from my iPhone

> On Nov 6, 2013, at 9:02, Pekka Jääskeläinen <pekka.jaaskelainen at gmail.com> wrote:
> 
> 
>  This looks good to me. A previous version of this pass is now in use in pocl and passes all tests (and accelerates many benchmarks) in its test suite when enabled. I will synch this version to the pocl kernel compiler soon.
> 
> 
> ================
> Comment at: include/llvm/Analysis/TargetTransformInfo.h:327
> @@ +326,3 @@
> +  /// with no vector support.
> +  virtual bool shouldDecomposeVectors() const;
> +
> ----------------
> This is now a target choice which should be OK for starters. Later we might want to extend this to look into the code as well. In OpenCL case, for example, sometimes the original vectored code is better than the autovectorized decomposed code, sometimes not. Same goes for all code that uses vector datatypes. 
> 
> ================
> Comment at: lib/Transforms/Scalar/DecomposeVectors.cpp:286
> @@ +285,3 @@
> +// llvm.mem.parallel_loop_access.
> +void DecomposeVectors::transferMetadata(Instruction *Op,
> +                                        const ValueVector &CV) {
> ----------------
> I'm not sure if it's safe to blindly transfer  all metadata. Isn't it against the MD principles: if a pass doesn't understand the metadata's purpose, it should drop it, and it should be the safe thing to do. I do not have an example in mind, but it might be safer to white list the known OK MD (which you already list in the function comment)?
> 
> 
> http://llvm-reviews.chandlerc.com/D2112
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits