patch: make instcombine remove shuffles by reordering vector elements

[Nadav Rotem]

Hi Nick, 

> I don't still have the motivating C++ source. A while ago when looking at .ll files produced with the loop vectorizer enabled, I noticed redundant shuffles and made a note to myself to write this optimization.

Thanks for bringing this up. One pattern that your patch can optimize is vectorization of loops with reverse iterators. For example:

for (i=n; i>0; i--) {
A[i] = B[i] * 2;
}

In this loop we will load the memory, reverse it, perform the operation, reverse it again, and store it. I am in favor of teaching inst-combine to remove both shuffles.  

> 
> The good news is that when this transform fires it always deletes one shuffle. We can still run the transform only to reorder insertelement indices (make it return false for all shufflevectors in CanEvaluateShuffled).

It would be great if you could write your optimization in a way that it would only delete shuffles (it should not create new shuffles). Also, I would like to limit the recursion depth to make sure we don't spend too much time on one instruction.  I am also okay with re-ordering insertelement instructions, but I am not sure how common they are. 

> If the backend is capable of lowering a bad shuffle to multiple shuffles instead of scalarizing then we can conclude that this patch at worst moves shuffles around.
> If the backend doesn't do that but we have some way of determining whether a shuffle is good or bad, we can use that to ensure we don't fold two good shuffles into a single bad one.
> 

The problem is that it is really difficult to do that. The search space is huge (think about Mic/XeonPhi shuffles where the vector size is 512 bits), and the instruction set is sparse. We lower x86 shuffles with 1000 lines of c++ code. So, there is no way to determine ahead of time if the shuffle is good or bad. Also, InstCombine is not the right place to do these kind of transformation because they are very target specific.
 

Thanks,
Nadav

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130504/53cef923/attachment.html>