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....@gcc.gnu.org> On Behalf Of Li, Pan2 via
Gcc
Sent: Tuesday, October 17, 2023 4:34 PM
To: Richard Biener <richard.guent...@gmail.com>
Cc: gcc@gcc.gnu.org; richard.sandif...@arm.com; juzhe.zh...@rivai.ai;
kito.ch...@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.guent...@gmail.com>
Sent: Tuesday, October 17, 2023 4:23 PM
To: Li, Pan2 <pan2...@intel.com>
Cc: gcc@gcc.gnu.org; richard.sandif...@arm.com; juzhe.zh...@rivai.ai;
kito.ch...@gmail.com
Subject: Re: Vectorizer for types with different size
On Mon, Oct 16, 2023 at 4:05 PM Li, Pan2 <pan2...@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
