Vectorizer for types with different size

Vectorizer for types with different size

[Li, Pan2]

Hi Richard Biener,

Recently I am try to enable the RISC-V auto-vec for the lrint family, which is trying to convert the HF/SF/DF to long type.

Then I found the vectorizer can only act on the types with the same data size. For example, DF to DI (long in RV64) works
well for standard pattern name lrintmn2 but fails on other combinations like SF to DI.

However, according the legacy hook TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION may help to resolve the problem
but I would like to learn if there is any plan that the middle-end would like to support the types with different size before we
start to implement the hook.

I also have a try for ARM for this, you can reference this link https://godbolt.org/z/o41hr9rY9.

Thanks in advance and have a great day, ;)!

Pan

Re: Vectorizer for types with different size

[Richard Biener]

On Mon, Oct 16, 2023 at 4:05 PM Li, Pan2 <pan2.li@intel.com> wrote:
>
> Hi Richard Biener,
>
> Recently I am try to enable the RISC-V auto-vec for the lrint family, which is trying to convert the HF/SF/DF to long type.
>
> Then I found the vectorizer can only act on the types with the same data size. For example, DF to DI (long in RV64) works
> well for standard pattern name lrintmn2 but fails on other combinations like SF to DI.
>
> However, according the legacy hook TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION may help to resolve the problem
> but I would like to learn if there is any plan that the middle-end would like to support the types with different size before we
> start to implement the hook.

I don't think using TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION would
help here?

It should be somewhat straightforward to support different vector size
when nunits_in == nunits_out, so
you could try just removing the restriction for that case in
vectorizable_call.  It's probably that the pre-selection
of vector types will make it so that this easy special case isn't ever
chosen though (I get WIDEN, but also
a matched vector size on x86).  The vectorizable_internal_function
selection then doesn't actually
check how the chosen vector types could be "split" - for both WIDEN
and NARROW we'd have to check
the associated vector types with the same number of lanes (obviously),
and either the input split
or the output composed then.

Richard.

>
> I also have a try for ARM for this, you can reference this link https://godbolt.org/z/o41hr9rY9.
>
> Thanks in advance and have a great day, ;)!
>
> Pan

RE: Vectorizer for types with different size

[Li, Pan2]

Thanks Richard Biener, will have a try and keep you posted.

Pan

-----Original Message-----
From: Richard Biener <richard.guenther@gmail.com> 
Sent: Tuesday, October 17, 2023 4:23 PM
To: Li, Pan2 <pan2.li@intel.com>
Cc: gcc@gcc.gnu.org; richard.sandiford@arm.com; juzhe.zhong@rivai.ai; kito.cheng@gmail.com
Subject: Re: Vectorizer for types with different size

On Mon, Oct 16, 2023 at 4:05 PM Li, Pan2 <pan2.li@intel.com> wrote:
>
> Hi Richard Biener,
>
> Recently I am try to enable the RISC-V auto-vec for the lrint family, which is trying to convert the HF/SF/DF to long type.
>
> Then I found the vectorizer can only act on the types with the same data size. For example, DF to DI (long in RV64) works
> well for standard pattern name lrintmn2 but fails on other combinations like SF to DI.
>
> However, according the legacy hook TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION may help to resolve the problem
> but I would like to learn if there is any plan that the middle-end would like to support the types with different size before we
> start to implement the hook.

I don't think using TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION would
help here?

It should be somewhat straightforward to support different vector size
when nunits_in == nunits_out, so
you could try just removing the restriction for that case in
vectorizable_call.  It's probably that the pre-selection
of vector types will make it so that this easy special case isn't ever
chosen though (I get WIDEN, but also
a matched vector size on x86).  The vectorizable_internal_function
selection then doesn't actually
check how the chosen vector types could be "split" - for both WIDEN
and NARROW we'd have to check
the associated vector types with the same number of lanes (obviously),
and either the input split
or the output composed then.

Richard.

>
> I also have a try for ARM for this, you can reference this link https://godbolt.org/z/o41hr9rY9.
>
> Thanks in advance and have a great day, ;)!
>
> Pan

RE: Vectorizer for types with different size

[Li, Pan2]

Hi Richard Biener,

Just have a try for the suggestion, remove the size check of vectorizable_call is able to generate the .LRINT standard name
from SF to DI, with below sample code. I will run a x86 bootstrap and regression test for this change.

void
test_lrintf (long *out, float *in, unsigned count)
{
  for (unsigned i = 0; i < count; i++)
    out[i] = __builtin_lrintf (in[i]);
}

void test_lrintf (long int * out, float * in, unsigned int count)
{
  vector([2,2]) long int * vectp_out.9;
  vector([2,2]) long int vect__7.8;
  vector([2,2]) float vect__4.7;
  vector([2,2]) float * vectp_in.5;
  unsigned long ivtmp_8;
  unsigned long _9;
  unsigned long ivtmp_22;
  unsigned long ivtmp_27;
  unsigned long ivtmp_30;
  unsigned long _31;

;;   basic block 2, loop depth 0
;;    pred:       ENTRY
  if (count_11(D) != 0)
    goto <bb 3>; [89.00%]
  else
    goto <bb 5>; [11.00%]
;;    succ:       3
;;                5

;;   basic block 3, loop depth 0
;;    pred:       2
  _9 = (unsigned long) count_11(D);
;;    succ:       4

;;   basic block 4, loop depth 1
;;    pred:       4
;;                3
  # vectp_in.5_26 = PHI <vectp_in.5_25(4), in_12(D)(3)>
  # vectp_out.9_21 = PHI <vectp_out.9_17(4), out_13(D)(3)>
  # ivtmp_8 = PHI <ivtmp_30(4), _9(3)>
  _31 = .SELECT_VL (ivtmp_8, POLY_INT_CST [2, 2]);
  ivtmp_27 = _31 * 4;
  vect__4.7_24 = .MASK_LEN_LOAD (vectp_in.5_26, 32B, { -1, ... }, _31, 0);
  vect__7.8_23 = .LRINT (vect__4.7_24);                                                                  // float (SF) to long int (DI)
  ivtmp_22 = _31 * 8;
  .MASK_LEN_STORE (vectp_out.9_21, 64B, { -1, ... }, _31, 0, vect__7.8_23);
  vectp_in.5_25 = vectp_in.5_26 + ivtmp_27;
  vectp_out.9_17 = vectp_out.9_21 + ivtmp_22;
  ivtmp_30 = ivtmp_8 - _31;

Pan

-----Original Message-----
From: Gcc <gcc-bounces+pan2.li=intel.com@gcc.gnu.org> On Behalf Of Li, Pan2 via Gcc
Sent: Tuesday, October 17, 2023 4:34 PM
To: Richard Biener <richard.guenther@gmail.com>
Cc: gcc@gcc.gnu.org; richard.sandiford@arm.com; juzhe.zhong@rivai.ai; kito.cheng@gmail.com
Subject: RE: Vectorizer for types with different size

Thanks Richard Biener, will have a try and keep you posted.

Pan

-----Original Message-----
From: Richard Biener <richard.guenther@gmail.com> 
Sent: Tuesday, October 17, 2023 4:23 PM
To: Li, Pan2 <pan2.li@intel.com>
Cc: gcc@gcc.gnu.org; richard.sandiford@arm.com; juzhe.zhong@rivai.ai; kito.cheng@gmail.com
Subject: Re: Vectorizer for types with different size

On Mon, Oct 16, 2023 at 4:05 PM Li, Pan2 <pan2.li@intel.com> wrote:
>
> Hi Richard Biener,
>
> Recently I am try to enable the RISC-V auto-vec for the lrint family, which is trying to convert the HF/SF/DF to long type.
>
> Then I found the vectorizer can only act on the types with the same data size. For example, DF to DI (long in RV64) works
> well for standard pattern name lrintmn2 but fails on other combinations like SF to DI.
>
> However, according the legacy hook TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION may help to resolve the problem
> but I would like to learn if there is any plan that the middle-end would like to support the types with different size before we
> start to implement the hook.

I don't think using TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION would
help here?

It should be somewhat straightforward to support different vector size
when nunits_in == nunits_out, so
you could try just removing the restriction for that case in
vectorizable_call.  It's probably that the pre-selection
of vector types will make it so that this easy special case isn't ever
chosen though (I get WIDEN, but also
a matched vector size on x86).  The vectorizable_internal_function
selection then doesn't actually
check how the chosen vector types could be "split" - for both WIDEN
and NARROW we'd have to check
the associated vector types with the same number of lanes (obviously),
and either the input split
or the output composed then.

Richard.

>
> I also have a try for ARM for this, you can reference this link https://godbolt.org/z/o41hr9rY9.
>
> Thanks in advance and have a great day, ;)!
>
> Pan