RFC: Enable vectorization of call instructions in the loop vectorizer

[Nadav Rotem]

> > I don’t like the vectorizer.call metadata because it does not solve the general problem. Yes, it will allow the vectorization of some OpenCL functions but it will not help the vectorization of other math functions in regular C loops. 
>  
> The difficulty I had is how to effectively model the transforms in a way that works for OpenCL (which, I admit, is the only case I care about at the moment) but also for whatever others may reasonably want to use it for. Is your argument that the constraints on whether vectorization of general math functions is possible cannot be expressed in metadata? I’m inclined to agree, which is why I initially pushed for the querying hook mechanism.
>  
> > I think that this kind of logic should go into TargetLibraryInfo, and not as part of the vectorizers.
>  
> This sounds similar to my original approach of adding hooks. And indeed, TargetLibraryInfo certainly sounds like the best place for them.

Yes :)

>  
> > I understand this problem but I don’t want to add OpenCL-specific knowledge into the loop-vectorizer.
>  
> I do understand your concern and I agree, but I don’t see how the solution I just proposed is OpenCL-specific… is it that the solution is just not applicable to other uses? (as mentioned in my first paragraph)

I guess that it is applicable to other DSL users, but I would like this solution to help vectorize c++ code.  Each operating system and each math library has a different set of vectorized functions and I would like the vectorizer to be able to use the available vectorizable functions in C++ code.  Renato’s #pragma work will increase the adoption of the vectorizer and the support of vectorizable functions will probably be one of the highest demands for people who use Renato’s vectorization pragmas.   

>  
> > One possible solution would be to work around this problem by extending your OpenCL library and by introducing OpenCL-specific passes that will detect these kind of patterns and optimize your vectorized code using the OpenCL knowledge. 
>  
> Totally doable. I’m very keen to add the “right” support upstream – I don’t expect upstream to solve my problem completely. I’m happy to do whatever cleanup or modifications are needed downstream to keep upstream uncluttered.
>  
> If I’ve understood you correctly (please let me know if I haven’t!) then I’ll get on creating a prototype using TLI hooks.
>  

Yes, I think that using TargetLibraryInfo Hooks is probably the best solution.  

Thanks,
Nadav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131216/94d2dd76/attachment.html>