[RFC][mid-end] Support vectorization of complex numbers using machine instructions.

[Tamar Christina]

Hi Richard,

> > [...]
> > 3) So I abandoned vec-patterns and instead tried to do it in
> > tree-vect-slp.c in vect_analyze_slp_instance just after the SLP tree
> > is created.  Matching the SLP tree is quite simple and getting it to
> > emit the right SLP tree was simple enough,except that at this point
> > all data references and loads have already been calculated.
> 
> (3) seems like the way to go.  Can you explain in more detail why it didn't
> work?  The SLP tree after matching should look something like this:
> 
>   REALPART_EXPR <*_10> = _4;
>   IMAGPART_EXPR <*_10> = _13;
> 
>   _4 = .COMPLEX_ADD_ROT_90 (_12, _8)
>   _13 = .COMPLEX_ADD_ROT_90 (_22, _6)
> 
>   _12 = REALPART_EXPR <*_3>;
>   _22 = IMAGPART_EXPR <*_3>;
> 
>   _8 = REALPART_EXPR <*_5>;
>   _6 = IMAGPART_EXPR <*_5>;
> 
> The operands to the individual .COMPLEX_ADD_ROT_90s aren't the
> operands that actually determine the associated scalar result, but that's
> bound to be the case with something that includes an internal permute.  All
> we're trying to describe is an operation that does the right thing when
> vectorised.
> 
> If you didn't have the .COMPLEX_ADD_ROT_90 and just fell back on mixed
> two-operator SLP, the final node would be in the opposite order:
> 
>   _6 = IMAGPART_EXPR <*_5>;
>   _8 = REALPART_EXPR <*_5>;
> 
> So if you're doing the matching after building the initial tree, you'd need to
> swap the statements in that node so that _8 comes first and cancel the
> associated load permute.  If you're doing the matching on the fly while
> building the SLP tree then the subnodes should start out in the right order.

Ah, I hadn't tried it this way because in the SLP version, I had originally started with looking
at the complex fma, which would have a considerably longer match pattern.

  _3 = c_14(D) + _2;
  _11 = REALPART_EXPR <*_3>;
  _21 = IMAGPART_EXPR <*_3>;
  _5 = a_15(D) + _2;
  _22 = REALPART_EXPR <*_5>;
  _12 = IMAGPART_EXPR <*_5>;
  _7 = b_16(D) + _2;
  _19 = REALPART_EXPR <*_7>;
  _20 = IMAGPART_EXPR <*_7>;
  _25 = _19 * _22;
  _26 = _12 * _20;
  _27 = _20 * _22;
  _28 = _12 * _19;
  _29 = _25 - _26;
  _30 = _27 + _28;
  _31 = _11 + _29;
  _32 = _21 + _30;
  REALPART_EXPR <*_3> = _31;
  IMAGPART_EXPR <*_3> = _32;

So In this case I should replace _31 and _32 right? but I can't remove the other statements otherwise it'll complain later about the missing references. I could replace _31 and _32 with something using all the variables I would need, however when I tried this previously in vect-patterns there was a block on build in functions with more than 4 arguments (and currently 3 is the limit for built in functions in the def file as well).  I don’t know if that same limitation is in place if I replace it in SLP.

The complex add basically creates this vector

 b⋅c - e⋅f + l 
 b⋅e + c⋅f + n

so I'd need 5 parameters and then I'm guessing the other expressions would be removed by DCE at some point?

Kind Regards,
Tamar

> 
> Thanks,
> Richard