[PATCH] Add a Scalarize pass

[Nadav Rotem]

Hi Richard, 

I think that it is a good idea to have a scalarizer pass for people who want to build llvm-based compilers, but I don’t think that this pass should be a part of the default pass manager.  Targets that want to scalarize the code should do it as part of instruction-selection (just declare the types as illegal).  Why do you want to control scalatization from the target ?  IMHO scalarization is only useful in undoing domain specific input IR.  

Nadav

On Nov 7, 2013, at 10:16 AM, Nadav Rotem <nrotem at apple.com> wrote:

>> 
>> On Nov 7, 2013, at 6:34, Richard Sandiford <rsandifo at linux.vnet.ibm.com> wrote:
>> 
>> Thanks for the reviews.  New in this version:
>> 
>> - The pass is called Scalarizer rather than DecomposeVectors.
>> 
>> - Alignment is taken into account.
>> 
>> - Only known metadata is kept.
>> 
>> - Loads and stores are kept as-is if the elements are not a whole number of bytes in size.  It's still useful to decompose vectors of <N x i1> comparison results though -- in fact that was one of the original motivations.
> 
> Excellent. Notice that we don't support bit packing of vectors to memory yet. So I am glad that you forbid vectors of sub byte elements. 
>> 
>> - Vector GEPs are scalarised too.  (I hadn't realised they were allowed, thanks.)
>> 
>> - There are more tests.  Let me know if there's something else I should be testing for though.
>> 
>> I tried adapting the llvm-stress wrapper in:
>> 
>>     http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-March/047876.html
>> 
>> to run opt at -O3 with -enable-scalarizer -scalarize-load-store.  The number of runs and instruction sizes were both 1000.  No problems were reported.
>> 
> 
> Great!
> 
>> The pass doesn't yet try to scalarise function calls.  At the moment we just gather/reassemble vectors whenever we have a use that isn't understood.  That's enough for my target but it could be extended in future.  (In the SystemZ llvmpipe code that I'm working with, the only function call is to sqrt.v4f32, but these testcases wouldn't benefit by scalarising that early.)
>> 
> 
> Thanks for making the changes. I am currently at the llvm dev mtg but I will try to review the patch ASAP. 
> 
> Nadav
> 
> 
>> http://llvm-reviews.chandlerc.com/D2112
>> 
>> CHANGE SINCE LAST DIFF
>> http://llvm-reviews.chandlerc.com/D2112?vs=5376&id=5399#toc
>> 
>> Files:
>> include/llvm-c/Transforms/Scalar.h
>> include/llvm/Analysis/TargetTransformInfo.h
>> include/llvm/InitializePasses.h
>> include/llvm/LinkAllPasses.h
>> include/llvm/Transforms/Scalar.h
>> lib/Analysis/TargetTransformInfo.cpp
>> lib/Transforms/IPO/PassManagerBuilder.cpp
>> lib/Transforms/Scalar/CMakeLists.txt
>> lib/Transforms/Scalar/Scalar.cpp
>> lib/Transforms/Scalar/Scalarizer.cpp
>> test/Transforms/Scalarizer/basic.ll
>> test/Transforms/Scalarizer/dbginfo.ll
>> test/Transforms/Scalarizer/no-data-layout.ll
>> <D2112.2.patch>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131109/3138f5ae/attachment.html>