[PATCH] D21354: Remove redundant direct moves when extracting integers and converting to FP

Nemanja Ivanovic via llvm-commits llvm-commits at lists.llvm.org
Wed Jun 15 01:55:37 PDT 2016

nemanjai added a comment.

I am not sure I fully follow what you are suggesting. I understand that you are suggesting that we should look more generally into why we are extracting a vector element to begin with (i.e. what the uses are). However, I do not follow if you feel this patch should be abandoned in the interest of a more general solution (for which we haven't even fully formulated the problem).
In my view, extracting an integer element and converting it to floating point was an outlier in terms of code quality and it is what this patch fixes.

Now, I understand that there are some general opportunities for improvement with operations that convert back and forth between integer vector and scalar/vector floating point values due to the fact that some of the floating point and vector registers overlap and this is unique to PPC. This kind of solution requires considering the best choices for not only each of the uses you mention here, but also for both the source and result types. However, I don't think that a complex, fully generalized solution is likely to be implemented very soon and we should tackle these outliers in code quality in small chunks like this when we spot them. Also, we need to weigh the complexity of the solution against how common we feel the code pattern might be in real code.

So to summarize, while I definitely agree that extractelement, insertelement, scalar_to_vector and build_vector ISD nodes would benefit from a DAG combine to handle various possible uses of the results, I feel that such a solution is rather involved and needs a careful examination of what we want the resulting DAG's to look like. Until we have formulated such a solution, I think we should fix the obviously poor code gen choices with quick fixes such as this patch.



More information about the llvm-commits mailing list