[PATCH] [SLPVectorization] Enhance Ability to Vectorize Horizontal Reductions from Consecutive Loads

[suyog]

Hi Michael,

Thanks for replying.

Two quick points to mention from your reply.

1. By swapping Right[i] with Left[i+1] after check, we are ensuring that resultant Left after swap are consecutive. We do not need to check if after swapping, Right is as well consecutive. If the resultant Right becomes consecutive, the bundling code ahead (already existing in SLP) will bundle it into a load vector as a result of which the cost model will calculate the cost of vectorization as negative and finally vectorize the whole code. If the resultant Right doesn't have consecutive loads, the bundling code ahead will not bundle these loads into vector, which in turn makes the cost of vector positive (expensive) and hence avoid vectorization of whole code.

2. The case you mentioned (a[0]+b[0])+(a[1]+b[1]) was already handled without this patch as well. Left - a[0] & a[1] and Right - b[0] & b[1] and hence vectorizable already.

  The twist in the example as u mentioned happens with (a[0]+b[0]) + (b[1]+a[1]), where Left - a[0] & b[1] and Right - b[0] & a[1] (though i am doubtful if this ever happens). Since we are checking Left[i] & Right[i] only, there won't be any swapping in this case and we won't vectorize this code, though it has potential to be vectorized.

  Now, since for reduction case of above type where we have a single tree we know that the Left and Right will always have size=2 because of the way tree is formed, we can actually eliminate loop and check all the 4 elements for consecutive loads.

  I would like to have your opinion on this - whether we should eliminate loop and just check 4 elements?

  I had run LNT test on similar patch submitted earlier for 10 iterations on X86 and i didn't see any significant improvement nor any regression, though the AArch64 assembly generated above is a good improvement.

I would also like to give context of earlier discussions on this whole exercise:

http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-September/076930.html
http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-November/078666.html

Waiting for your suggestions.

Regards,
Suyog


REPOSITORY
  rL LLVM

http://reviews.llvm.org/D6675

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/