[PATCH] D19544: Pass for translating math intrinsics to math library calls.

[Hal Finkel via llvm-commits]

hfinkel added a comment.

In http://reviews.llvm.org/D19544#416269, @mmasten wrote:

> Thanks for the feedback, Hal. We need the clang support because we actually have several variants of each svml function, each of them having varying levels of precision. To be able to pick the right variant, not only do we need to know the variant name and vector length, we also need the additional precision information specified by the user via -imf flags from the command line.


I'm aware, however:

1. We need to break this into smaller pieces. We can start with adding support for some subset of the functions using our current infrastructure, and then extend that infrastructure.
2. We need to have a separate design discussion on the Clang flags and other aspects of the user interface (pragmas, attributes, etc.).

> If we go the route of implementing the translation using the addVectorizableFunctionsFromVecLib(), it seems some additional information about precision requirements would be needed in the VecDesc struct.


Yes, or the tables become callback functions, or any number of other things.

> One thing I'm concerned about with this approach is that if the math calls are translated immediately to library calls, then any subsequent optimizations are probably in a less advantageous position of being able to optimize further. Thus, one of the design goals of this project was to keep the vectorized intrinsics as late as possible before translation. What are your thoughts on this?


This is a valid concern. However, we currently vectorize very late in the pipeline, and so the only optimizations we're talking about are optimizations that would not have applied to the original scalar instructions, but might now apply to the vector instructions. I can't think of anything that falls into this category, but if you can, please elaborate.

> I apologize for throwing such a large patch at you guys. I was afraid that might be the case. I'll try and keep the changes to a minimum going forward.


You don't need to apologize. We still need to break this into smaller bits. However, it is completely reasonable to post a large change first, and then get community feedback on how to split it up.


http://reviews.llvm.org/D19544