Please review: Optimize vector multiply on X86

Andrea_DiBiagio at sn.scee.net Andrea_DiBiagio at sn.scee.net
Wed Jun 19 10:09:29 PDT 2013


Hi Elena,

> From: "Demikhovsky, Elena" <elena.demikhovsky at intel.com>
> I did the MUL optimization common for all targets. Please review.

Your function 'isSplatVector' returns true also when elements are not all 
the same.
Example: a vector of four i64 defined as <i64 4, i64 0, i64 0, i64 0> is 
still considered to be a valid splat
with a SplatBitSize equale to the vector size.

With your patch, if I run
llc -mtriple=x86_64-apple-darwin -mcpu=core-avx2 -mattr=+avx2 
on the following function:

define <8 x i32> @mul_const1(<8 x i32> %x) {
  %y = mul <8 x i32> %x, <i32 2, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, 
i32 0>
  ret <8 x i32> %y
}

I get that the multiply is wrongly combined into
vpaddd %ymm0, %ymm0, %ymm0

Another example is:
define <4 x i64> @mul_const2(<4 x i64> %x) {
  %y = mul <4 x i64> %x, <i64 4, i64 0, i64 0, i64 0>
  ret <4 x i64> %y
}

here the multiply is wrongly combined into
vpsllq $2, %ymm0, %ymm0

If you want to make sure that isSplatVector returns 'true' _only_ in the 
case where the elements of a BUILD_VECTOR are exactly the same (or Undef), 
then you should check both SplatBitSize and HasAnyUndefs. Alternatively in 
`isSplatVector' you could implement a loop that checks if each operand of 
the BUILD_VECTOR is either Undef or the same ConstantSDNode.

I hope this helps!
Andrea Di Biagio
SN Systems - Sony Computer Entertainment Group

**********************************************************************
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify postmaster at scee.net
This footnote also confirms that this email message has been checked for 
all known viruses.
Sony Computer Entertainment Europe Limited
Registered Office: 10 Great Marlborough Street, London W1F 7LP, United 
Kingdom
Registered in England: 3277793
**********************************************************************

P Please consider the environment before printing this e-mail



More information about the llvm-commits mailing list